2.4.21: bug report for tg3: tx lockup when changing MTU

2.4.21: bug report for tg3: tx lockup when changing MTU

[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.

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

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: 2.4.21: bug report for tg3: tx lockup when changing MTU

[Jeff Garzik]

Ben Greear wrote:
> 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?

Re: 2.4.21: bug report for tg3: tx lockup when changing MTU

[Ben Greear]

Jeff Garzik wrote:
> Ben Greear wrote:
> 
>> 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?

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.





-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: 2.4.21: bug report for tg3: tx lockup when changing MTU

[Sascha Schumann]

> 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.

    [1] http://www.google.de/search?q=cache:y_kVF_dR3TkJ:www.lanshop.co.uk/html/ga302tq.htm+netgear+ga302t+jumbo+frames&hl=de&ie=UTF-8

    - Sascha

Re: 2.4.21: bug report for tg3: tx lockup when changing MTU

[Ben Greear]

Sascha Schumann wrote:
>>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

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com