Re: b43 doing tx-status reports with NULL frames?

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 2916 bytes --]


> > That WARN_ON is:
> > 
> >         if (WARN_ON(!skb))
> >                 return;
> > 
> > This was with dma overflow injection and a few patches, but nothing
> > relevant inside b43.
> 
> hm, this is interesting.
> 
> Is it this one?
> 1379                 if (meta->is_last_fragment) {
> 1380                         B43_WARN_ON(!meta->skb);

Uh, yes. I had added one in mac80211 (see above) because it crashed for
me at that place once, but that one triggered as well:


May  7 13:04:02 johannes kernel: [  847.811168] Badness at drivers/net/wireless/b43/dma.c:1380
May  7 13:04:02 johannes kernel: [  847.811174] NIP: f2530de4 LR: f2530dc8 CTR: f252ff70
May  7 13:04:02 johannes kernel: [  847.811182] REGS: d191bb20 TRAP: 0700   Not tainted  (2.6.25-wl-06933-g0bacadf-dirty)
May  7 13:04:02 johannes kernel: [  847.811188] MSR: 00021032 <ME,IR,DR>  CR: 48242484  XER: 00000000
May  7 13:04:02 johannes kernel: [  847.811205] TASK = d1918000[5078] 'wpa_supplicant' THREAD: d191a000
May  7 13:04:02 johannes kernel: [  847.811211] GPR00: 00000001 d191bbd0 d1918000 edb89248 00000208 d191bbd8 00000000 000003cc 
May  7 13:04:02 johannes kernel: [  847.811230] GPR08: 00000001 00000000 00010004 edb89200 48242488 10083d28 100e0000 100876e9 
May  7 13:04:02 johannes kernel: [  847.811249] GPR16: 100876d9 100876b1 22042442 0000008a 00000002 1006071c ed88703c 00000000 
May  7 13:04:02 johannes kernel: [  847.811268] GPR24: d191bbd8 f2537d24 ee513120 d191bc28 00000001 0000029e 00000041 ed887000 
May  7 13:04:02 johannes kernel: [  847.811288] NIP [f2530de4] b43_dma_handle_txstatus+0xd4/0x2e8 [b43]
May  7 13:04:02 johannes kernel: [  847.811336] LR [f2530dc8] b43_dma_handle_txstatus+0xb8/0x2e8 [b43]


> The "is_last_fragment" actually means "is last s/g fragment".
> (not 802.11 fragment).

Right, I know :)

> So basically this assertion checks the presence of the skb buffer
> for each s/g fragment. We use two s/g fragments for each TX packet.
> One for the header and one for the skb. You already know that.
> So, for the first s/g fragment we have meta->skb=NULL and for the
> second meta->skb!=NULL.
> I'm not sure why this assertion triggers. I can't see where in the TX path
> the allocation of the slots or the meta->skb assignment can go wrong.
> Allocation basically always allocates the ring descriptors in pairs.
> Either both or none (in case of a DMA error, but _not_ an overflow).
> The ring suspend (or suspend injection) basically is independent from
> the allocation.
> 
> Can you add the following assertion into b43_dma_tx() after the
> b43_dma_tx_fragment call, please?
> 
> WARN_ON(free_slots(ring) & 1);
> 
> This shouldn't ever trigger, as we always allocate the slots in pairs.

I don't even know if I can reproduce this, sorry. Also, if I can, with
my patch to put things into skb->cb it'll all just crash...

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]