everybody knows that interrupt handler should be short as possible. and adding functions like printk
for debugging inside an interrupt handler is something that shouldn't be done.
Actually, I tried it before when I was debugging the linux kernel for an interrupt driven char device I written, and it wrecked the timing of the driver.
The question I have, is why this is happening ?
printk
function is buffered ! it means, as far as I understand that the data is inserted in to a queue, and it's being handled later, most probably after the interrupt handler is finished.
So why doesn't it work ?
The printk
function is not just inserting into a queue/buffer -- assuming the log level is high enough, the output from printk
will be emitted to the console immediately, as part of the call to printk
. This is especially slow if the console is, say, on a serial port. But in any case, printk
does introduce pretty substantial overhead and can affect timing.
If you have a timing critical place where you want to get some debug output, you can look at using the trace_printk
function in modern kernels. This actually does just put input into the trace ringbuffer, and you can read it later. Take a look at this article for full details.