USB problems

[John Birrell]

On Thu, Dec 30, 2004 at 11:16:31AM -0700, M. Warner Losh wrote:
> In message: <20041228010938.GA39686 at freebsd3.cimlogic.com.au>
>             John Birrell <jb at cimlogic.com.au> writes:
> : 1. The USB sub-system doesn't handle loading and unloading drivers properly.
> :    If a driver is unloaded when a USB device is still attached, the next
> :    time the driver is loaded, the kernel panics. This might not be such
> :    a problem to normal users because they don't have a need to do that, but
> :    during driver development when you want to load and unload repeatedly,
> :    it's a pain.
> 
> I don't see this.  Can you give a more concrete example?  I've done
> work in this area and I believe that it is almost working correctly.

What I see is that my driver is detached, the USB device still exists
and so does the device_t. The generic probe and attach bus code goes
through each driver and tries to probe the device. However, since the
probe and attach hasn't come from uhub, the attach_args and quirks
haven't been set up. The kernel invaribly panics accessing a NULL quirk
pointer.

The 'concrete' example here (as best I can give one) is that the USB device
is already known to uhub and no USB event has been seen for it. The only
thing that has happened is that a driver is loaded which tries to probe,
via generic probe and attach (since there is no specific uhub_driver_loaded
- which I believe there should be).

> : 3. The usbd_bulk_transfer function calls tsleep() to wait for streaming
> :    data to become available. On current, this bumps into a KASSERT in
> :    msleep because Giant is not locked and no mutex has been supplied.
> :    In my driver, I need to run an 'encoder' thread which calls
> :    usbd_bulk_transfer() to gobble the incoming MPEG data stream. While
> :    this is going on, there is no syscall in progress because the
> :    application is off doing other things. It might be looking at the
> :    mmaped buffer or it may not.
> : 
> :    For FreeBSD, usbd_bulk_transfer() needs to change to allow the driver
> :    to specify it's mutex. I don't know what the implications are for
> :    uhci given that it hasn't been converted to use mutexes. Can anyone
> :    comment on that?
> 
> I have changes to make sure this can't happen as well.  But you must
> hold Giant whenever you call into the usb subsystem.

Yuk. How long is Giant held? Is it only while the transaction is queued
and de-queued?

> I already deal with these things, are you sure you're looking at the
> current code?  Well, I Don't deal with ugen, but when I have to load
> drivers I don't include it in my kernel.  There's no harm in that.
> I'm working on a generic newbus way of dealing with this situation,
> but acpi does non-idempotent things in its probe routines :-(.

I am definitely using the current code. I leave ugen out because it
only gets in my way.

During development and because of the frequency of panics in FreeBSD's USB
implementation, I build usb and uhci into the kernel which I net-boot. Then
I run a test which loads the driver, tries to open and talk to the device,
closes the device and unloads the driver. I expect to be able to do this
a few times - once for each test. At present the kernel panics on the
second test.

-- 
John Birrell