On Mon, 2009-07-27 at 17:59 +0200, Johannes Berg wrote: > On Mon, 2009-07-27 at 11:34 -0400, Pavel Roskin wrote: > > > If you mean "verify info->control.vif is not NULL", it makes no > > difference for me. No BUG is triggered. info->control.vif is never > > NULL in ieee80211_tx_pending(), but sdata->dev is NULL the second time > > ieee80211_tx_pending() is called. Just skipping that case doesn't help, > > I still get a panic in that function after about 10 calls. > > Weird. > So where does it panic if you skip with sdata->dev == NULL? > > I don't see how sdata->dev can possibly be NULL. Hmm. Ok, I think we may > not be recycling things correctly. Is it possible that this is a frame > that was rejected by the device, or maybe a frame that was attempted to > transmit, but then got into software retransmit? I have to leave now for an hour or two, but I'll review that code after I return. It's possible that this never happened before because skb->iif wasn't touched by drivers, but skb->cb is. Actually, you're using ath5k, right? So we can see what info->control.vif points to after ath5k has used the skb, because apparently it's a valid pointer at least, just not a real vif pointer any more. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part