2.4.21: bug report for tg3: tx lockup when changing MTU
Subsystems (2)
I just noticed that if you change the MTU of a tg3 NIC, it will not work untill you ifdown/ifup it. This problem is repeatable on tg3, and does not happen with the e1000 driver/cards.
I am setting the MTU via an ioctl call, not via ifconfig or something like that.
When the tg3 is locked up, I see this on the console:
Aug 1 15:05:44 demo2 kernel: NETDEV WATCHDOG: eth5: transmit timed out Aug 1 15:05:44 demo2 kernel: tg3: eth5: transmit timed out, resetting Aug 1 15:05:44 demo2 kernel: tg3: tg3_stop_block timed out, ofs=2400 enable_bit=2 Aug 1 15:05:44 demo2 kernel: tg3: tg3_stop_block timed out, ofs=1400 enable_bit=2 Aug 1 15:05:44 demo2 kernel: tg3: tg3_stop_block timed out, ofs=c00 enable_bit=2 Aug 1 15:05:54 demo2 kernel: NETDEV WATCHDOG: eth5: transmit timed out Aug 1 15:05:54 demo2 kernel: tg3: eth5: transmit timed out, resetting Aug 1 15:05:54 demo2 kernel: tg3: tg3_stop_block timed out, ofs=2400 enable_bit=2 Aug 1 15:05:54 demo2 kernel: tg3: tg3_stop_block timed out, ofs=1400 enable_bit=2
...
Kernel is 2.4.21 + custom patches (which should not affect tg3).
lspci says the NIC is: Altima AC9100 (rev 15)
I will be happy to provide more information as needed.
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 6 lines · Ben Greear
I just noticed that if you change the MTU of a tg3 NIC, it will not work untill you ifdown/ifup it. This problem is repeatable on tg3, and does not happen with the e1000 driver/cards.
I am setting the MTU via an ioctl call, not via ifconfig or something like that.
Can you provide the ioctl call info, so I can reproduce?
And, are you changing MTU when the interface is up or down?
Quoted 6 lines · Jeff Garzik
Quoted 4 lines · Ben Greear
I just noticed that if you change the MTU of a tg3 NIC, it will not work untill you ifdown/ifup it. This problem is repeatable on tg3, and does not happen with the e1000 driver/cards.
Quoted 8 lines
Quoted 2 lines
I am setting the MTU via an ioctl call, not via ifconfig or something like that.
Can you provide the ioctl call info, so I can reproduce?
And, are you changing MTU when the interface is up or down?
Interface is up and transmitting/receiving pkts at the time.
I just reproduced it with commands below. It is probably a race, so not sure that either of these will always fail. Running about 10kpps rx+tx. Was sending pktgen (UDP) traffic of fixed length, so the actual transmitted packet sizes remains the same in this case.
# MTU is at 1500
ifconfig eth5 mtu 4096 #worked
ifconfig eth5 mtu 4000 # failed.
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 3 lines
Kernel is 2.4.21 + custom patches (which should not affect tg3).
lspci says the NIC is: Altima AC9100 (rev 15)
[1] says that the AC9100 based Netgear GA302T cards don't support jumbo frames. I'm seeing regular lockups once packets larger than 1500bytes flow through the NIC.
It would be cool though if this turned out to be a driver limitation and not a (crippled) chipset issue.
- Sascha
Quoted 11 lines · Sascha Schumann
Quoted 3 lines
Kernel is 2.4.21 + custom patches (which should not affect tg3).
lspci says the NIC is: Altima AC9100 (rev 15)
[1] says that the AC9100 based Netgear GA302T cards don't support jumbo frames. I'm seeing regular lockups once packets larger than 1500bytes flow through the NIC.
It would be cool though if this turned out to be a driver limitation and not a (crippled) chipset issue.
It definately handles 4000 byte frames just fine, you just need to ifdown and ifup it after changing the MTU much of the time...or maybe only when running it under heavy load when you make the MTU change...
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com