> 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." -- 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
