On 03/26/2013 10:16 AM, Adrian Chadd wrote:
... and the odd thing here is that during scanning, it should be flushing the queues entirely so any new frame being transmitted _SHOULD_ result in: * TxDP for that queue being written (either FIFO or otherwise); * TxE for that queue being set. So unless the queue is "full" already and isn't being drained, I'm kinda curious as to why TX isn't starting.
At least for the problems I saw, it was fairly easy to spot the problem once you looked at the xmit debugfs file. There would be 127 pending-frames, axq-depth and ampdu-depth were zero, queue is stopped, and it stays like that for many seconds or minutes. Just resetting the NIC didn't help...I had to also tell the reset to not retry any packets and to set the pending-frames to zero. After that, packets started transmitting again, and often after several seconds I'd see at least most of the old stuck packets be processed to one degree or another (pending frames would go negative since I had forced it to zero earlier). I still do not know the root cause of this, nor have I had time to look at it in any more detail..the work-around is good enough for me for now and I have higher priority issues currently... I only saw the problem in the data queue (BE), but maybe it can happen in other queues as well. Or of course it could be completely un-related to the problem in this email thread.... Thanks, Ben -- Ben Greear <greearb@xxxxxxxxxxxxxxx> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
