On 29/10/21(Fri) 14:48, Alexandre Ratchov wrote: > 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).
Then this is correct, thanks a lot. Please go ahead, ok mpi@
