Thanks to both of you. I admit I did this kind of prematurely. I’ll give removing the flag a shot next week! Cheers, Diez Von meinem iPad gesendet > Am 11.10.2018 um 21:01 schrieb Julia Cartwright <julia@xxxxxx>: > > 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
