The airo driver tries to avoid excessive latencies when issuing commands to the card by calling schedule() after several retries. But issuecommand() can be run from an interrupt handler. The function is careful enough to check with in_atomic() if it is safe to call schedule(). This check breaks when the interrupt handler is threaded, because then in_atomic() is always false there. The handler is run as TASK_INTERRUPTIBLE, so schedule() takes it off the runqueue and it never wakes up again. Here's an obvious fix - simply don't call schedule() when using preemptible hardirqs. An improved solution might be to identify the commands that take so long to issue and avoid sending them from the interrupt handler. In my testing there was only one such command: CMD_ACCESS. I need to investigate if it's always possible to delay it to airo's kthread.
Signed-off-by: Michal Schmidt <[EMAIL PROTECTED]> diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c index 44a2270..98014c0 100644 --- a/drivers/net/wireless/airo.c +++ b/drivers/net/wireless/airo.c @@ -3938,8 +3938,10 @@ static u16 issuecommand(struct airo_info *ai, Cmd *pCmd, Resp *pRsp) { if ((IN4500(ai, COMMAND)) == pCmd->cmd) // PC4500 didn't notice command, try again OUT4500(ai, COMMAND, pCmd->cmd); +#ifndef CONFIG_PREEMPT_HARDIRQS if (!in_atomic() && (max_tries & 255) == 0) schedule(); +#endif } if ( max_tries == -1 ) { - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/