Bug 16168

There's a problem with simultanous use of multiple USB endpoints on a
device.  Consider the following sequence of actions:

1.  plug in USB device with multiple endpoints, such as a Handspring
Visor.

2.  open /dev/ugen0 to get a handle on the control endpoint.

3.  open /dev/ugen0.2 to get a handle on a bulk endpoint on which
bidirectional transfers will occur.

3.  perform an ioctl(ugen0_fd, USB_SET_CONFIG, &one) operation.

3a.  then kernel will invoke ugen_set_config() in sys/dev/usb/ugen.c.  This
will perform a memset(sc->sc_endpoints, 0, sizeof sc->sc_endpoints).  Note
this zap the state associated with step (3) above, in particular,
the pipeh member of the struct ugen_endpoint structure.

4.  perform a select, read or write system call on the fd associated
with /dev/ugen0.2.  If DIAGNOSTIC is not defined, you'll eventually
dereference the pipeh structure member mentioned above.

Fix: 

"It hurts when I do that.  Well, don't do that!"

Clearly, whacking the application program to perform all diddling
with the device configuration on the control endpoint before opening
the bulk endpoint is easy to do.  However, doing these operations in
the "wrong" order shouldn't cause the kernel to panic.

One simple approach is to removed the conditional #ifdef DIAGNOSTIC
around the tests in ugenpoll, ugen_do_read, ugen_do_write, etc, so that
a panic() is avoided.  This somehow seems unsatisfactory.  I suspect
that I don't completely grok the structure of the USB driver stack to
suggest a more tasteful alternative.

Perhaps some of the ioctl()'s that reset the state of the driver for
a device should be prohibited if any other endpoints are currently
open?

louie
How-To-Repeat: 
As described.