Re: bnx2_poll panicking kernel

["Michael Chan" <mchan@broadcom.com>]

Josip Rodin wrote:
> On Mon, Jun 23, 2008 at 08:04:39PM +0200, Josip Rodin wrote:
>> Oh, duh, yes, I'm a moron. It's back on now, sorry about that.
> 
> There we go, I got the debugging messages:
> 
> [...]
> Jun 23 19:53:18 arrakis kernel: HTB: quantum of class 10100 is big. Consider r2q change.
> Jun 23 22:57:55 arrakis kernel: bnx2: skb->nr_frags=1 is corrupted, should be 4
> Jun 23 22:58:32 arrakis kernel: bnx2: skb->nr_frags=1 is corrupted, should be 2
> Jun 23 22:59:02 arrakis kernel: bnx2: skb->nr_frags=1 is corrupted, should be 3
> Jun 23 22:59:23 arrakis kernel: bnx2: skb->nr_frags=1 is corrupted, should be 9
> Jun 23 22:59:36 arrakis kernel: bnx2: skb->nr_frags=1 is corrupted, should be 3
> Jun 23 23:08:19 arrakis kernel: bnx2: skb->nr_frags=1 is corrupted, should be 3
> 

OK, this definitely confirms the theory that the skb->nr_frags is changed
between ->hard_start_xmit() and tx completion.  Since we rely on nr_frags to
locate the packet boundaries in the tx ring, it would definitely crash.

One possibility is that it is corrupted by the driver and only happens when
there are HTB rules.  I think this is unlikely.

TG3 which operates the same way has also been reported to crash in the
presence of HTB rules.  We were not able to pinpoint the problem at that
time.

Can anyone think of a scenario where the stack can modify the SKB this way?
These SKBs look like they are TSO packets.  

If not, I will send Josip another patch to print more SKB fields.  I can
even save all the SKB fields and see which other ones are modified besides
the nr_frags.  May be that will give us a better clue.

Thanks.