I added some gigabit cards to my boxes this past week. Unfortunately, these older boxes rarely even achieve 15MB/s, so it’s hardly worth it.
Even more fun, it appears that my cards, which use the tg3 driver, fail when under a load on my Supermicro 370DLE ServerWorks IIILE chipset based board. What’s more, my Broadcom BCM95700 based gigabit card fails to function with the tg3 driver. There is presently no known fix, so I am using Broadcom’s own bcm5700 non-free driver.
For both cards, I end up with these errors, which show up in Google, but with no known resolution after several years. I have to assume it’s rather isolated and only happens with some mainboard and tg3 driver supported card combinations. (My older P3 with a PIIx based chipset works fine with two different tg3 driver supported cards.)
These are for my BCM95700 card, which has few hits in Google and fails to work with the tg3 driver. However, it fails under the same circumstances as my tg3 driver supported card when in my Supermicro 370DLE system.
NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out nfsd: last server has exited nfsd: unexporting all filesystems NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out nfsd: last server has exited nfsd: unexporting all filesystems
And here we have failures for the tg3 driver supported card:
tg3: eth1: Link is up at 1000 Mbps, full duplex. tg3: eth1: Flow control is on for TX and on for RX. tg3: eth1: Link is down. tg3: eth1: Link is up at 1000 Mbps, full duplex. tg3: eth1: Flow control is on for TX and on for RX. NETDEV WATCHDOG: eth1: transmit timed out tg3: eth1: transmit timed out, resetting tg3: tg3_stop_block timed out, ofs=1400 enable_bit=2 tg3: tg3_stop_block timed out, ofs=c00 enable_bit=2 tg3: eth1: Link is down. tg3: eth1: Link is up at 1000 Mbps, full duplex. tg3: eth1: Flow control is on for TX and on for RX. NETDEV WATCHDOG: eth1: transmit timed out tg3: eth1: transmit timed out, resetting tg3: tg3_stop_block timed out, ofs=1400 enable_bit=2 tg3: tg3_stop_block timed out, ofs=c00 enable_bit=2 tg3: eth1: Link is down. tg3: eth1: Link is up at 1000 Mbps, full duplex. tg3: eth1: Flow control is on for TX and on for RX. NETDEV WATCHDOG: eth1: transmit timed out tg3: eth1: transmit timed out, resetting tg3: tg3_stop_block timed out, ofs=1400 enable_bit=2 tg3: tg3_stop_block timed out, ofs=c00 enable_bit=2 tg3: eth1: Link is down. tg3: eth1: Link is up at 1000 Mbps, full duplex. tg3: eth1: Flow control is on for TX and on for RX.
As of today, I know of no known solution. I am bagging this experiment and sticking in my older ns83820 based card, which I hope will work. It failed to work under 2.6.7 and below last summer without a patch. I don’t recall if that patch even applies to later kernels and thus stuck with 2.6.4 for six months.
Failing that, it’s back to the old, trusty on-board Intel Ethernet. Given my recent performance tests, I’ll only be losing out on another 5MB/s versus what the 100Mbps Intel card delivers, and that’s only in a few best case scenarios. Often I don’t see speeds much inexcess of 100Mbps with my gigabit cards on my ancient hardware.