(Added Marco and me in the CC - please keep it) On Sunday, March 24, 2013 11:40:27 PM Robert Shade wrote: > > Hm, so it's doing some fast channel changes? > > Yes, the fastcc does seem to work, it's just that sometimes the chip > can get in a bad state when it's not cold reset. > > 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? > > Just disabling fastcc was not enough, the cold resets are what seemed > to have made the difference. I was actually thinking about > re-enabling fastcc and testing again. > > The TXE/RXE checking path is from felix's "ath9k_hw: improve reset > reliability after errors" patch. I've just got the exception in there > for 9160, since I don't have other hardware to test with. What do the > hardware engineers say about warm vs. cold reset? I did notice that > your latest ar9300 HAL has a note stating that "Warm reset is > optimistic." Marco reported in "carl9170: monitor mode hangs due to channel changes" <http://www.spinics.net/lists/linux-wireless/msg105100.html> that carl9170 would stop receiving frames after some time. I looked a bit closer look and it seems that the fast channel change for AR9170 also seems to be the culprit in this case. (It seems that the AGC_CONTROL register is suddenly (re-)set by something to "0x20" (default is 0x0004dd20) and then everything stops.) Regards, Christian -- 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
