From owner-freebsd-arch Sun Oct 13 15:36:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6873737B401 for ; Sun, 13 Oct 2002 15:36:30 -0700 (PDT) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1ECAA43EA9 for ; Sun, 13 Oct 2002 15:36:28 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: from freebsd1.cimlogic.com.au (localhost.cimlogic.com.au [127.0.0.1]) by cimlogic.com.au (8.12.6/8.12.6) with ESMTP id g9DMaNVe039192 for ; Mon, 14 Oct 2002 08:36:23 +1000 (EST) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.12.6/8.12.6/Submit) id g9DMaNhd039191 for arch@freebsd.org; Mon, 14 Oct 2002 08:36:23 +1000 (EST) Date: Mon, 14 Oct 2002 08:36:23 +1000 From: John Birrell To: arch@freebsd.org Subject: USB driver design issues Message-ID: <20021014083622.G261@freebsd1.cimlogic.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have a few problems with the design of the USB drivers in FreeBSD. From the investigation I've done so far, the problems appear to arise from the inability of the code to handle kldload and kldunload. The result is that I can crash a RELENG_4 kernel (and probably a -current one too since the USB driver code is similar) simply by connecting or disconnecting the USB cable. Sub-optimal. I was working on a driver for the Belkin VideoBus II (a video capture thingy). Like other custom drivers I have, this one has a test harness that kldloads the driver, opens it, does a few things, closes and kldunloads it. Connecting the USB cable after the driver is loaded causes the USB drivers to correctly probe and attach the device. The probe and attachment process hangs a USB pointer off the device 'ivar' hook. When the device is closed and the driver unloaded, the kernel code NULLs the 'driver' pointer in the device, but leaves the 'ivar' pointer set. The USB code continues to remember that the cable is connected, but there is now no device for it. Disconnecting the cable at this point crashes the kernel as it tries to use the device to report the event to usbd. If the cable isn't disconnected, but the driver module is kldloaded again, the kernel calls the driver_module_handler code which tries to probe and attach the device, using the bogus 'ivar' pointer and this crashes the kernel. What I think the USB code /should/ do (the reason for posting to this list) is to use the driver_loaded callback to ensure that it's list of USB devices 'connected' to the hub is updated as driver modules are loaded and unloaded. For example, if a USB scanner device (say) is already connected and powered up, but the uscanner driver isn't loaded, then the device will appear as 'ugen'. If the uscanner driver is subsequently loaded, the USB code should re-discover that device as 'uscanner'. If the uscanner driver is unloaded, then the device should go back to 'ugen'. Comments? (BTW, I've tried emailing Nick Hibma about this, but I haven't had a reply yet. It's only been a few days though.) -- John Birrell To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message