On Fri, Oct 29, 2021 at 01:12:06PM +0100, Martin Pieuchot wrote: > On 29/10/21(Fri) 13:12, Alexandre Ratchov wrote: > > On Sat, Oct 23, 2021 at 10:40:56AM +0100, Martin Pieuchot wrote: > > > Diff below switches both poll(2) and select(2) to the kqueue-based > > > implementation. > > > > > > In addition it switches libevent(3) to use poll(2) by default for > > > testing purposes. > > > > > > I don't have any open bug left with this diff and I'm happily running > > > GNOME with it. So I'd be happy if you could try to break it and report > > > back. > > > > > > > Without the below diff (copied from audio(4) driver), kernel panics > > upon the first MIDI input byte. > > What is the panic? The mutex is taken recursively, right? >
Exactly, this is the "locking against myself", panic. AFAIU, the interrupt handler grabs the audio_lock and calls midi_iintr(). It calls selwakeup(), which in turn calls filt_midiread(), which attempts to grab the audio_lock a second time. > > ok? suggestion for a better fix? > > Without seeing the panic, I'm guessing this is correct. > > That suggest kevent(2) wasn't safe to use with midi(4). > Yes, this is the very first time midi(4) is used with kevent(2).
