On 2025-01-29 14:59:19 [-0700], Jillian Donahue wrote: > > So a simple "tasklet_hi_schedule(&midi->tasklet);" instead of "f_midi_transmit(midi)" in f_midi_complete() might do the trick. > > This fixes the problem - do you have any insight to how this worked in > the first place? Trying to understand the change. There are possibilities. The problem is that you send a packet and it completes the same moment and the completion callback is invoked which deadlocks. Now: - PREEMPT_RT may have moved the timing a bit (makes it behave a bit different or simply make a UP device behave like a SMP one) to the point that it sees the completion of the request where it did not before. So does it occur without PREEMPT_RT? - It never did work in this combination even without PREEMPT_RT. The driver (f_midi) was never tested with the USB device controller you have and the one it was tested with behaves differently so the recursion never occurred. - It is an old driver (f_midi). It was never tested on SMP or with enabled lock testing. On UP spinlocks end up almost as NOPs so a deadlock (as in this case) will not be observed. Either way I would blame f_midi here. Once you have the pieces together, mind sending a patch? Sebastian
