Re: Hang/reboot with -current and umidi on i386

[Tom Ivar Helbekkmo <tih%hamartun.priv.no@localhost>]

I wrote:

> Right, I got it to put me in ddb instead.  It's actually the assertion
> at line 264 of /sys/dev/usb/umidi.c that fails:
>
>       KASSERT(KERNEL_LOCKED_P());
>
> and the backtrace is:
>
> usbd_transfer() /* this contains the assertion above */
> start_input_transfer()
> umidi_open()

So, I did the obvious thing:

Index: umidi.c
===================================================================
RCS file: /cvsroot/src/sys/dev/usb/umidi.c,v
retrieving revision 1.55
diff -u -r1.55 umidi.c
--- umidi.c     23 Dec 2011 00:51:47 -0000      1.55
+++ umidi.c     27 Jan 2012 23:19:16 -0000
@@ -1415,12 +1415,19 @@
 static usbd_status
 start_input_transfer(struct umidi_endpoint *ep)
 {
+       usbd_status rv;
+
+       DPRINTFN(200,("umidi in transfer: start %p length %u\n",
+           ep->buffer, ep->buffer_size));
+       KERNEL_LOCK(1, curlwp);
        usbd_setup_xfer(ep->xfer, ep->pipe,
                        (usbd_private_handle)ep,
                        ep->buffer, ep->buffer_size,
                        USBD_SHORT_XFER_OK | USBD_NO_COPY,
                         USBD_NO_TIMEOUT, in_intr);
-       return usbd_transfer(ep->xfer);
+       rv = usbd_transfer(ep->xfer);
+       KERNEL_UNLOCK_ONE(curlwp);
+       return rv;
 }
 
 static usbd_status

This is a partial win.  It now lets me open USB MIDI interfaces for
reading, and they work.  (Write only worked already.)  However, the
system now crashes when I close ports that have been open for read.

The message is:

kernel diagnostic assertion "ci->ci_mtx_count == -1" failed: file
"/usr/src/sys/kern/kern_sync.c", line 748 mi_switch: cpu1: ci_mtx_count
(-2) != -1
fatal breakpoint trap in supervisor mode

Backtrace shows:

mi_switch()
sleepq_block()
usb_delay_ms()
uhci_abort_xfer()
usbd_abort_pipe()
close_in_jack.clone.3()
umidi_close()
midiclose()
spec_close()
VOP_CLOSE()
closef()
fd_free()
exit1()
sigexit()
postsig()
lwp_userret()
syscall

Now, these things don't need to be synched on close - it's perfectly
normal for a MIDI channel to have input buffered that stays unread as it
gets closed.  Might that be the problem here?

On the other hand, the actual crash seems to be a mutex-related thing...

-tih
-- 
"The market" is a bunch of 28-year-olds who don't know anything. --Paul Krugman