Bug 37172

(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Fri, 10 Jun 2011 19:20:58 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=37172
> 
>            Summary: Enabling 802.1q vlan causes some packets to be
>                     received with a vlan id of 64
>            Product: Networking
>            Version: 2.5
>     Kernel Version: 2.6.39
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Other
>         AssignedTo: acme@ghostprotocols.net
>         ReportedBy: a.reversat@gmail.com
>         Regression: Yes

From which kernel version did we regress?  Was 2.6.38 OK?

Thanks.

> 
> Created an attachment (id=61502)
>  --> (https://bugzilla.kernel.org/attachment.cgi?id=61502)
> Packet capture of problem
> 
> I added a vlan to my main network card by doing :
> 
> vconfig add eth0 6
> 
> Then I got huge packet loss when pinging e.g google (around 70% packet loss).
> 
> After checking a packet capture it seems that some packets come in with a
> vlan
> tag even though they shouldn't. In my capture I see them with a vlan id of 64
> where they shouldn't even be 802.1q tagged.
> 
> Kernel version is 2.6.39 and I am using the forcedeth driver so I don't know
> if
> it is related to the network stack or the forcedeth driver.
> 
> Attached is the relevant capture. Note how packet with seq 2 for instance is
> tagged and packet with seq 5 isn't.
> 
> I'll test this with the latest 3.0 rc and update the bug report if the
> problem
> is fixed in there.
>

On Mon, Jun 13, 2011 at 7:43 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
>
> From which kernel version did we regress?  Was 2.6.38 OK?

I can confirm this bug is present in 2.6.38.6

I'll try and see if I can reproduce it on a 2.6.37

I've tested 2.6.37.6 and 3.0.0-rc2 and the bug is still reproducible
in both kernels. I'll try a 2.6.36 to see if it was present in it too.

Has this been tested on other hardware ? I'm still unsure if it's a
driver issue or if it's something else.

On Tue, Jun 14, 2011 at 9:31 AM, Antoine Reversat <a.reversat@gmail.com> wrote:
> On Mon, Jun 13, 2011 at 7:43 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
>>
>> From which kernel version did we regress?  Was 2.6.38 OK?
>
> I can confirm this bug is present in 2.6.38.6
>
> I'll try and see if I can reproduce it on a 2.6.37
>

On Wed, Jun 15, 2011 at 12:13 PM, Antoine Reversat <a.reversat@gmail.com> wrote:
> I've tested 2.6.37.6 and 3.0.0-rc2 and the bug is still reproducible
> in both kernels. I'll try a 2.6.36 to see if it was present in it too.
>
> Has this been tested on other hardware ? I'm still unsure if it's a
> driver issue or if it's something else.
>

Infact it's probably a driver bug : I've tried on a coworkers computer
with a different network adapter and it works flawlessly. I'll contact
the forcedeth people about this.

Hi,

I found this bug too few days ago on my MB M2N68-AM Plus with this NIC:

00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2)
        Subsystem: ASUSTeK Computer Inc. Device 83a4
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 45
        Memory at dfdf9000 (32-bit, non-prefetchable) [size=4K]
        I/O ports at d480 [size=8]
        Capabilities: [44] Power Management version 2
        Capabilities: [50] MSI: Enable+ Count=1/8 Maskable+ 64bit+
        Capabilities: [6c] HyperTransport: MSI Mapping Enable- Fixed+
        Kernel driver in use: forcedeth

It's behavior is the same as Antoine Reversat. My kernel is 2.6.39-1.1-amd64, basic debian kernel with IMQ patch added, but this is not affect any drivers.

Same combination with e100/e1000/e1000e or tg3 driver works fine.

Best regards.

Hi Adrian,

this issue has been fixed, see this link : http://marc.info/?l=linux-netdev&m=130825723922977&w=2

It is integrated in the latest 2.6 tree.

Antoine