Problems with a deadlock in the interrupt handler thread

Topics: Developer Forum
Feb 21, 2008 at 2:38 PM
The project I am working on uses AR6K driver based on this one, but slightly extended. I am having a problem where the SDIO interrupt handler acquires SDBus internal lock and proceeds to call AR6K request dispatcher. Dispatcher then decides that it needs to send some frames in response to the data it has read from the device, which results in a HtcSendFrame trying to acquire txCS lock and blocking on it. The reason for it to block is because another thread has tried to send some data (e.g. a TCP/IP transfer) and got this far, inside HtcSendFrame only to block on the SDBus internal lock held by the interrupt thread I mentioned before. Honestly, I simply don't understand how is it supposed to work. SHouldn't any writes done from the dispatcher be queued separately, and executed after interrupt handler has returned?
Feb 23, 2008 at 12:39 AM
To be more specific, a problem occurs when the device that is connected is asked to connect to another AP. This is done via sending a disconnect command and then queing a WmiConnect command to be invoked from WmiDisconnectInidication. Since WmiDisconnectInidication is invoked synchronously from the SDIO ISR, and the WmiConnect command takes time, there is a chance that by the time Connect internally tries to acquire txCS lock in htcSendFrame, it is already held by a different thread that is in turn locked inside htcSendFrameLocked and is locked by SDIOBus internal lock. But SDIOBus lock is held by the first thread because it still sits in ISR. Essentially the issue as I see it is that instead of releasing the ISR thread ASAP and doing async processing, things are done directly in the ISR thread. Is there something I am missing?
Mar 30, 2008 at 10:00 PM
I suspect you are using one of the versions of the SDIO2 bus driver. It has issues with holding locks during CIRQ handling. It does seem to think that an ISR should be able to queue cmds. I believe there are some flags in latter versions of the driver that work around this. You could switch back to the SDIO (original) bus driver