Date: Fri, 7 Jan 2005 11:57:01 +1100 From: John Birrell <jb@cimlogic.com.au> To: "M. Warner Losh" <imp@bsdimp.com> Cc: usb@freebsd.org Subject: Re: USB problems Message-ID: <20050107005700.GC55403@freebsd3.cimlogic.com.au> In-Reply-To: <20041230.111631.13597845.imp@bsdimp.com> References: <20041228010938.GA39686@freebsd3.cimlogic.com.au> <20041230.111631.13597845.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 30, 2004 at 11:16:31AM -0700, M. Warner Losh wrote: > In message: <20041228010938.GA39686@freebsd3.cimlogic.com.au> > John Birrell <jb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050107005700.GC55403>