On Wed, 30 Sep 2009, Remy Bohmer wrote: > > The serial irq cannot run in hard irq context. > > Indeed most drivers cannot, but for this particular handler can you > please explain me why? > Maybe I am missing some new mechanism that prevents it that was not > there on older RT-kernels (tested up-to latest 2.6.24-rt + > 2.6.26-rt)... Which had the same problem .... > The atmel_serial IRQ was adapted such (I think it was mainlined in > 2.6.25 already) to make it suitable to run in hard-irq context. (I > know, because I did that myself) That's fine for mainline but not for -rt. > FWIW... it seems to run stable in hard-irq context on 2.6.31-rt with > the patch above as well... (coincidence?) Yes. The serial code takes locks which are converted to sleeping locks on -RT. That's a nono. > > 2) Make the serial driver explicitely threaded and check in the > > hardirq handler whether the irq originated from the serial driver. If > > yes, disable it in the serial device and return IRQ_WAKE_THREAD > > otherwise return IRQ_NONE. > > Interesting, this sounds new, and I have to dig into it to find out > how this is supposed to work... Do you happen to have any good > pointers for examples or doc? drivers/net/wireless/b43/main.c in mainline > TOL: could the generic interrupt code not check for this? It can see > the timer interrupt handler not returning 'IRQ_HANDLED', and still see > the interrupt being active, and know that there is a IRQ thread on the > same line, so it can conclude itself to mask the source in the > interrupt controller and wake the thread... Or am I wrong? What happens if both are active at the same time ? Also masking the interrupt line will block your timer interrupts until the threaded handler has completed. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
