New: tg3 + jumbo frames + scatter-gather == inoperative NIC
Subsystems (2)
A message that is not in the archive (sent off-list or not yet received): [email protected]/
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
Quoted 56 lines · On Tue, 22 Jul 2008 12:45:54 -0700 (PDT) [email protected] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=11147
Summary: tg3 + jumbo frames + scatter-gather == inoperative NIC Product: Drivers Version: 2.5 KernelVersion: 2.6.25.9 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Network AssignedTo: [email protected] ReportedBy: [email protected]Latest working kernel version: n/a
Earliest failing kernel version: 2.6.25.9
Distribution: openSUSE 11.0
Hardware Environment: 32bit x86 (AMD Athlon XP 2200+) Software Environment: openSUSE 11.0
Problem Description:When I enable jumbo frames the board still *appears* to work but nobody can communicate with it. The other machines (multiple) in the network don't see ANY traffic FROM the tg3. On the machine with the tg3, tcpdump shows arp requests (from the other machines) and arp replies.
After much work, I have determined the problem to be a combination of scatter-gather and jumbo frames. When both are used, the card does not work correctly. Disabling *either* appears to work but no benefit is realized until the interface is brought down and back up again.
An "ethtool -t eth0" shows a single failed test (registers). I have a register dump and anything else anybody might want if this can be useful in bug-fixing.
I also saw this:
tg3: DEBUG: MAC_TX_STATUS[00000008] MAC_RX_STATUS[00000006]
tg3: DEBUG: RDMAC_STATUS[00000000] WDMAC_STATUS[00000000]
tg3:tg3_stop_blocktimed out, ofs=1400 enable_bit=2
tg3:tg3_stop_blocktimed out, ofs=c00 enable_bit=2Steps to reproduce:
I've also tried the tg3.[c,h] compiled against 2.6.25.9 but using the latest git source from either linux-2.6 or netdev-2.6 as of 17 July 2008.
tg3.c:v3.92.1 (June 9, 2008)
thetg3.csha1sum is97c198a8152045f2e7da5fe0d702df1cd185cb8d.
What other information can I provide?
This is 100% reproducible.
Signature · 1 line
Jon
Quoted 3 lines · Jon Nelson
What other information can I provide?
This is 100% reproducible.
Please provide lspci output and tg3 signon output so that we know what device is failing.
Quoted 8 lines · Michael Chan
Quoted 3 lines · Jon Nelson
What other information can I provide?
This is 100% reproducible.Please provide lspci output and tg3 signon output so that we know what device is failing.
OK. I added the output of:
{ lspci -t ; lspci -vvv; lspci -k -xxx ; } > lspci-all.frank
as an attachment to the bug.
Also:
frank:~ # ethtool -t eth0
The test result is FAIL
The test extra info:
nvram test (online) 0 link test (online) 0 register test (offline) 1 memory test (offline) 0 loopback test (offline) 0 interrupt test (offline) 0
frank:~ #
So, I added the output of:
ethtool -d eth0
Now. The above is all with 1500 byte frames.
If I switch to 9000 byte frames and take the interface down and then back up again, I am unable to communicate with it, *provided* scatter-gather is also enabled (which it is by default).
Quoted 1 line
From a cold boot (and 1500 byte frames):
frank:~ # ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
frank:~ #
I'll be adding ethtool -d using 9000 byte frames in the next 30 minutes. Is there anything else I can provide?
Signature · 1 line
Jon