On 24 March 2013 11:55, Robert Shade <robert.shade@xxxxxxxxx> wrote: > I've done some more testing on this and it looks like the auth packets > aren't delayed, they're never sent. The "TX Complete" messages are > from the queue being purged before a reset due to channel change. Ew, ok. > It only gets in this state when it's unable to change the channel due > to the timeout on setting the AR_PHY_AGC_CONTROL register. One thing > that does look interesting is that, when we fail to change the > channel, ath_complete_reset is never called and therefore > ieee80211_wake_queues is never called either. Are stop/wake queues > calls supposed to be balanced? I'll leave that up to Felix. > Based on your suggestions, I've been testing a few days with the > following patch and I have yet to see any DMA messages or the auth > stuck state. I had to check for SC_OP_INVALID because the initial > reset in ath9k_start would cause a kernel panic when the system was > being initialized from a powered off state. I don't know enough about > the internals to know if I should expect that, but I'll need to set up > a serial console in order to capture the panic. Hm, so it's doing some fast channel changes? Just disable fast channel change entirely and re-test? And why not just force a cold reset always? Why bother checking for the queue to be stopped? Adrian -- 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
