Created attachment 61502 [details] 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.
(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