Hello Diez- On Thu, Oct 11, 2018 at 04:30:36PM +0000, Diez Roggisch wrote: > Hi, > > during work on a driver I encountered a behaviour I can't explain and > would like to hear the opinion of the experts here. > > We work with the rasperry PI 3 (in it's compute module incarnation, > but that shouldn't make a difference for this discussion). > > It is hooked up to a microcontroller via SPI, and because the uC needs > to signal that it is ready to receive data, we strung an IRQ line to a > GPIO on the pi. > > In the driver I register an ISR for that GPIO which signals a > wait_queue_head_t with wake_up. The ISR is allocated with > IRQF_NO_THREAD because this is on our critical path and should be as > fast as possible. Can you reproduce the hanging behaviour without IRQF_NO_THREAD? In general, the signalling/wakeup of wait queues is not allowed from hardirq context (like what would happen if you've passed IRQF_NO_THREAD at the time you register your handler). If there's ever contention on the waitqueue's internal spin_lock on RT, the handler will end up trying to schedule() in a non-schedulable context. This might lead to a complete hang like you're seeing. Good luck, Julia
