Re: 2.6.31-rt11 freeze on userland start on ARM

[Thomas Gleixner <tglx@linutronix.de>]

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