New hardware, old problem: stuck beacon when here is WiFi traffic

[Adrian Chadd]

Hi,

Next time you do this, can you do this:

wlandebug +crypto +assoc +state

I'd like to see what's actually going on behind the scenes.

so:


May  9 21:08:59 gateway sudo:      lev : TTY=pts/1 ;
PWD=/usr/home/lev/bin ; USER=root ; COMMAND=/sbin/sysctl
dev.ath.0.debug=0x900000020

.. then a bunch of time, which I guess is you doing UDP:
May  9 21:16:25 gateway kernel: ath0: ath_tx_tid_drain_print: norm:
node 0xffffff8000d7f000: bf=0xffffff800085d8e0: addbaw=0, dobaw=0,
seqno=715, retry=0
May  9 21:16:25 gateway kernel: ath0: ath_tx_tid_drain_print: node
0xffffff8000d7f000: bf=0xffffff800085d8e0: txq[1] axq_depth=502,
axq_aggr_depth=0
May  9 21:16:25 gateway kernel: ath0: ath_tx_tid_drain_print: node
0xffffff8000d7f000: bf=0xffffff800085d8e0: tid txq_depth=1
hwq_depth=503, bar_wait=0, isfiltered=0
May  9 21:16:25 gateway kernel: ath0: ath_tx_tid_drain_print: node
0xffffff8000d7f000: tid 0: sched=1, paused=0, incomp=0, baw_head=0,
baw_tail=0 txa_start=51018, ni_txseqs=61249

.. so:

* hardware queue depth is 502 frames
* no aggregates
* there's only one frame in the TID txq, but 503 frames from that TID
in the hardware queue
* it's scheduled for more frames but there's likely no space left in the TXQ.

But there's no hardware reset until you do a forcebstuck.

So I guess that first one is actually a disassociate/reassociate bug
more than anything.

I bet this is what is actually going on. Can you please do the
wlandebug above, so we can see if it's actually disassociating and not
transitioning back through SCAN/ASSOC states?

Thanks,



adrian