> One is in ieee80211_if_set_type at the only point where I can see u.ap.ps_bc_buf could get > initialised and as I suspected that doesn't get called. > case IEEE80211_IF_TYPE_AP: > sdata->u.ap.dtim_period = 2; > sdata->u.ap.force_unicast_rateidx = -1; > sdata->u.ap.max_ratectrl_rateidx = -1; > skb_queue_head_init(&sdata->u.ap.ps_bc_buf); > printk( KERN_DEBUG "Initiatilsing ps_bc_buf at %p\n",&sdata->u.ap.ps_bc_buf); > sdata->bss = &sdata->u.ap; > break; > The other is in ieee80211_tx_h_multicast_ps_buf just before tx->sdata->bss->ps_bc_buf gets > used. I haven't quite followed what ap structure bss should be pointing to at that time but I'm > presuming whatever it is doesn't contain an initialised ps_bc_buf hence the lock failure. > > printk( KERN_INFO "About to queue skb %p to buffer %p\n",tx->skb, &tx->sdata->bss->ps_bc_buf); > skb_queue_tail(&tx->sdata->bss->ps_bc_buf, tx->skb); At that point, sdata->bss should point to the master device, which apparently hasn't been initialised yet. The device initialisation code is pretty black magic to me, Jiri/Michael? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
