Bug 4883

Summary: (net tg3) doesn't send ARP reply on 8021q VLAN interfaces
Product: Drivers Reporter: Alexey Dobriyan (adobriyan)
Component: NetworkAssignee: Jeff Garzik (jgarzik)
Status: REJECTED INSUFFICIENT_DATA    
Severity: normal CC: bunk, hmh, mh+kernel-bugzilla, protasnb, rberger
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.12.2 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: Quick fix / workaround for the tg3 driver vlan-arp bug

Description Alexey Dobriyan 2005-07-14 01:05:46 UTC 
From: Marc Haber <mh+usenetspam200516@zugschlus.de>
http://marc.theaimsgroup.com/?t=112106607700003&r=1&w=2

this morning, I tried upgrading a firewall from Debian woody to Debian
sarge, and in the course upgrading from a locally compiled vanilla 2.4.30
to a locally compiled vanilla 2.6.12.2. The box is a hp DL 140 which has
two tg3-based Interfaces on board, and a dual-Interface E1000 PCI card in
its PCI slot:

$ lspci
0000:00:00.0 Host bridge: ServerWorks GCNB-LE Host Bridge (rev 32)
0000:00:00.1 Host bridge: ServerWorks GCNB-LE Host Bridge
0000:00:03.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
0000:00:0f.0 ISA bridge: ServerWorks CSB6 South Bridge (rev a0)
0000:00:0f.1 IDE interface: ServerWorks CSB6 RAID/IDE Controller (rev a0)
0000:00:0f.2 USB Controller: ServerWorks CSB6 OHCI USB Controller (rev 05)
0000:00:0f.3 Host bridge: ServerWorks GCLE-2 Host Bridge
0000:00:10.0 Host bridge: ServerWorks CIOB-E I/O Bridge with Gigabit Ethernet
(rev 12)
0000:00:10.2 Host bridge: ServerWorks CIOB-E I/O Bridge with Gigabit Ethernet
(rev 12)
0000:01:06.0 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet
Controller (Copper) (rev 01)
0000:01:06.1 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet
Controller (Copper) (rev 01)
0000:02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit
Ethernet (rev 02)
0000:02:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit
Ethernet (rev 02)

The box uses dot1q VLANs on all interfaces.

After rebooting, the VLANs on the Intel-based interfaces worked fine, while
the tg3-based interfaces didn't answer to tagged ARP requests. The untagged
VLAN on the tg3-based interfaces was fine as well. When tcpdumping the
subinterfaces, I saw all traffic on the network, and especially the
incoming ARP requests, but no ARP replies went out.

Rebooting back to 2.4 solved the issue immediately, all VLANs were OK as
well.

Conclusion: Since the e1000-based VLANs work fine even with 2.6, the dot1q
code seems to be ok. So, the issue most probably lies with the tg3 driver.
Comment 1 Adrian Bunk 2006-03-08 13:35:58 UTC 
Is this issue still present in recent 2.6 kernels?
Comment 2 Adrian Bunk 2006-04-22 05:16:58 UTC 
I'm assuming this issue is already fixed in recent 2.6 kernels.

Please reopen this bug if it's still present in kernel 2.6.16.
Comment 3 Tuomas Toivola 2006-12-19 03:48:50 UTC 
The bug is still present in kernel 2.6.19.1 with the tg3 driver v3.69 which
comes with the kernel.
Comment 4 Tuomas Toivola 2006-12-19 03:56:15 UTC 
Created attachment 9882 [details]
Quick fix / workaround for the tg3 driver vlan-arp bug

After applying the patch, you'll need to load the module with parameter
"tg3_always_keep_vlan_tag=1".
Comment 5 Henrique de Moraes Holschuh 2007-10-08 15:30:44 UTC 
I use tg3 (Broadcom Corporation NetXtreme BCM5751M Gigabit Ethernet PCI Express (rev 11)/0200: 14e4:167d, kernel 2.6.22.9 (tg3 v3.77).

The driver identifies the PHY as: Tigon3 [partno(BCM95751M) rev 4101 PHY(5750)] (PCI Express) 10/100/1000Base-T Ethernet.

Capabilities set at boot by driver are:
  RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[1]
  dma_rwctrl[76180000] dma_mask[64-bit]

No problems with VLAN ARP here.

eth-tool says this about the state of the driver:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
udp fragmentation offload: off
generic segmentation offload: off

So, maybe this problem was fixed, OR it is a quirk of certain tg3 adapters but not all?
Comment 6 Natalie Protasevich 2007-11-05 21:40:49 UTC 
What is the current status with this problem for everyone? Does the driver work with recent kernels?
Thanks.