From owner-freebsd-usb@FreeBSD.ORG Fri Jan 7 00:57:03 2005 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AB1D16A4CE for ; Fri, 7 Jan 2005 00:57:03 +0000 (GMT) Received: from freebsd3.cimlogic.com.au (adsl-20-121.swiftdsl.com.au [218.214.20.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12CE043D5A for ; Fri, 7 Jan 2005 00:57:02 +0000 (GMT) (envelope-from jb@cimlogic.com.au) Received: by freebsd3.cimlogic.com.au (Postfix, from userid 102) id 390956A9BF; Fri, 7 Jan 2005 11:57:01 +1100 (EST) Date: Fri, 7 Jan 2005 11:57:01 +1100 From: John Birrell To: "M. Warner Losh" Message-ID: <20050107005700.GC55403@freebsd3.cimlogic.com.au> References: <20041228010938.GA39686@freebsd3.cimlogic.com.au> <20041230.111631.13597845.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041230.111631.13597845.imp@bsdimp.com> User-Agent: Mutt/1.4.2.1i cc: usb@freebsd.org Subject: Re: USB problems X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2005 00:57:03 -0000 On Thu, Dec 30, 2004 at 11:16:31AM -0700, M. Warner Losh wrote: > In message: <20041228010938.GA39686@freebsd3.cimlogic.com.au> > John Birrell 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