I just realized that the outer loop "while (uio->uio_resid > 0)" is NOT needed at all in midi_read, which solves the problem. We must return as soon as some data is read.

Two different processes cannot have an opened descriptor to the same MIDI device. So, I think the only problematic case is when a process opens the device and a child thread is waiting in blocking mode; if the descriptor is closed by the parent thread, will this properly stop the blocking read?

If M_RX gets unset, the device file was closed, so no read will occur anymore and draining or keeping data is useless. I made a successful test with this extra lock/unlock.

I've no doubt now that MIDI will work, although my set of patches is slightly different from yours, but please make incremental patches over this one, so we can see what is changed!

I suggest you to commit D54129 and my mpu_init changes (+changes here) so that we can make proper tests and incremental changes over it more simply.

I see. You may only have to check for M_RX inside the loop and not at line 433 (file closed), in addition to the extra lock/unlock.

I'm not convinced we have to unlock here, but this may give a breathe to the interrupt, so why not (during my last test I found too much latency but I don't know yet if it is relative to my userspace code or not).

Still not sure this is good. It is working as-it for me; uiomove will not sleep if the lock is taken just above!

For the midi module, I think the right path is:

Well, I tried to create a bugzilla account last week, but could not manage to get a password!

To fix the termination problem I mentioned above, I think you can simply remove the midi_uninit call in mpu401_uninit (if you want to keep this as a module).

Sorry, I can apply diff 54125 but no 54126 over it ?

Don't forget that some cards, as my common Soundblaster, have two ports; they actually appear as /dev/midi0.0 and /dev/midi0.1, which is useful to know that they belong to the same card.

I don't think it is a good idea to not build this as a module because this code will not be used by a large majority of hosts (although personally I'll appreciate to use MIDI on FreeBSD!).

Sorry for duplicating my message on Github for #1904, I found this patch (D54129) to be working on top of FreeBSD 15.0 release source, with my last update for #1904 (mpu_init.c), and the MIDI enabled for my Audigy2 soundcard (#1905).

You can compare the body of my midi.c/midi_read function with yours. What is difficult with this file is that there is a lot of small changes to do everywhere.

I triggered the kernel panic using my changes from the PR1902 from github.

Currently, opening the midi device in blocking mode triggers a kernel panic (line 442), but opening with O_NONBLOCK works well. Furthermore I think the data queues do not work properly (midiq.h).