Date: Mon, 14 Oct 2002 08:36:23 +1000 From: John Birrell <jb@cimlogic.com.au> To: arch@freebsd.org Subject: USB driver design issues Message-ID: <20021014083622.G261@freebsd1.cimlogic.com.au>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021014083622.G261>