On Mon, Jun 2, 2014 at 12:32 PM, Emmanuel Grumbach <egrumbach@xxxxxxxxx> wrote: >>> Note that the CMD queue (9 or 4 depending on your configuration) - uses another mechanism that is safer but consumes more power. This queue is intended for commands and not for real Tx packets. >> >> If that's queue 4 in the debugfs tx_queues file, then I think that >> that's the queue that keeps moving when the card is dead. I'll see if >> I can improve the tx_queues file to show pending updates. >> >> Yay troubleshooting old hardware. >> > If you plan to spend some time hacking on the code, please take into > account this code has been changed in 3.14 (mostly cleanups by > Johannes and myself). > Also note that long ago, I disabled shadow registers (you'll see ifs > all over the code). Shadow registers makes the whole wakup thing much > easier since it is handled internally in the HW. BUT we had tons of > issues with it so we disabled it. Most of the issues should have gone > away with the cmd_in_flight thing. So I would recommend you to give it > a try with shadow register enabled. Just check the relevant iwl-XXXX.c > file. Will do. FWIW, I looked at the cmd_in_flight thing and, unless there's a bunch of locking magic going on, it looks racy. It seems like some code expects it to be protected by reg_lock, and other code expects it to be protected by txq_lock (and there are multiple txq->lock instances, I think). Also, what stops the card from going to sleep while processing a wakeup interrupt? For example, what prevents this chain of events? The only thing I can see is that the only thing that clears ACCESS_REQ is the rx interrupt processing, which happens after wakeup processing, but this seems rather fragile. --Andy -- 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
