>Number:         23987
>Category:       kern
>Synopsis:       umidi locks up on second open for reading
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 05 05:48:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     Andreas Gustafsson
>Release:        NetBSD 1.6ZG
>Organization:
>Environment:
System: NetBSD guava.araneus.fi 1.6ZG NetBSD 1.6ZG (GUAVAMP) #0: Sat Dec 20 14:10:47 PST 2003 gson@guava.araneus.fi:/usr/src/sys/arch/i386/compile/GUAVAMP i386
Architecture: i386
Machine: i386
>Description:

In umidi.c, a USB bulk transfer is started to read data from the
adapter when the midi device is opened for reading (in open_in_jack()),
but the transfer is not aborted when the device is closed.
Hence, when the device is opened for a second time, will be two active
transfers, and badness ensues.

>How-To-Repeat:

Method 1:

Build a kernel with the DIAGNOSTIC option.

Connect a USB midi adapter (I use an Edirol UM-1SX, but any supported
adapter should give the same results).  Note the midi device number
printed in the attach message on the console.  There is no need to 
connect any MIDI devices to the adapter.

Run the following command *twice* (adjust the "1" as needed to match
the actual attached device number):

   true </dev/rmidi1

Notice that the a message like the following is printed on the console:

   usb_insert_transfer: xfer=0xc0ccee00 not busy 0x4f4e5155

Method 2:

I don't think you need a DIAGNOSTIC kernel in this case.

Connect an USB adapter as above.

Connect a MIDI keyboard or other device sending MIDI events to the
MIDI IN port.

Run the following command (again, adjust the "1" as needed):

   od -x </dev/rmidi1

Generate some MIDI events by playing on the keyboard (or equivalent),
and see that the events are displayed on the terminal in hex.  Abort
the "od" with control-C and restart, twice.  Notice that on the third
run, incoming MIDI events are no longer displayed.

>Fix:

I would fix this myself, but I'm not sure what the right way to abort
the transfer is, with the usbdi(9) man page being as incomplete as it
is.
>Release-Note:
>Audit-Trail:
>Unformatted: