> > 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:
signature.asc
Description: This is a digitally signed message part
