I have a question regarding the behavior of the driver I am developing, about the waiting queues and irq handling. I enable irq with request_threaded_irq()
, where I define a minimal irq_handler, and a threaded_irq_handler to run more processing.
At a point in time, my main process, in my wait4confirmation() function, will stop on a call to wait_event_interruptible_timeout()
, waiting to be woken up by a call to wake_up_interruptible()
at the end of the threaded_irq_handler.. This works well for most of the cases.
However, sometimes, when my driver is in under stressed conditions, I can see (with debug traces) that I call wake_up_interruptible() as expected, but then I re-enter my irq_handler and my threaded_irq_handler again, and sometimes interrupts may come so often that I reach the timeout of my waiting queue on the other side.
I would have expected the sleeping process to be woken up/scheduled at least before the new call to the threaded_irq_handler but this is not the case.
In order to have more information, I have printed out the current process which is running when passing in the three locations, and I am a bit puzzled:
- wait4confirmation(), just before stopping on the waiting queue -> wait4cfm Process is "ifconfig" (PID 280)
- irq_handler -> ipc_irq_hdlr Process is "ifconfig" (PID 280)
- threaded_irq_handler -> ipc_irq_thread_hdlr Process is "irq/36-rwnx_dri" (PID 277)
So, my questions are:
- Why my main process which is supposed to be woken up is never scheduled when I receive many interrupts, which makes me reach the timeout?
- Is it normal to see that my threaded_irq_handler is executed under irq process? And my irq_handler under my main process? Or is there something wrong when I print the processes out? (I call: printk("xxx Process is \"%s\" (PID %i)\n", current->comm, current->pid); )
Sorry for this long topic but I wanted to give as many information as possible, since I have made many searches on the web without success. Thanks in advance for your help.