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

[Iain Hibbert <plunky%rya-online.net@localhost>]

On Sat, 28 Jan 2012, Tom Ivar Helbekkmo wrote:

> 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:

I think you are on the right track but you should probably take the kernel
lock around the start_input_transfer() call in open_in_jack(), instead of
during the function, since it is called from other paths (eg in_intr) with
the kernel lock held?

> 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.

I don't know if that is because the kernel lock is now taken multiple
times as per your patch (or maybe that is allowed but I didn't think so in
general)

> 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()

or it could be that this call to usbd_abort_pipe() occurs without the
kernel lock held.. should it be at that point?

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

Yes, there has been some work with MP locking in the USB and audio
subsystems committed recently

iain