On Saturday 18 September 2004 8:18 pm, Alan Stern wrote: > The "known bug" is that when an HCD module is rmmod'ed it doesn't wait for > all the USB device refcounts to go to 0 -- but when they do a routine in > the HCD is called to release some memory.
That should be nearly fixable now, if it isn't already. The endpoint disable work got rid of all "live" state (connected to the hardware), so there should be no reason not to tell the HCD to get rid of any per-device memory they may have allocated, after all the drivers have disconnected. > Of course, if the HCD code has > already been unloaded from the system this causes an oops, as you found > out. There are other ways to delay USB device refcounts besides > usb-storage; it's possible to trigger the same bug using usbfs for > example. That sometimes made significant issues in 2.4 kernels, since the HCDs had no way to decide when to get rid of that "live" state other than by trusting to the kindness of strange drivers. That trust was easily betrayed, by some disconnect() method that lied ... easy to give the hardware indigestion and cause an oops, that way. An annoying one, since by definition it wasn't the driver with broken disconnect() that was oopsing! This OOPS in the SCSI code is analagous. Last I heard, it really didn't know how to deal with some "unexpected disconnect" cases; not ready for fully hotpluggable devices, as from USB (or several other busses). I think that once that hot-unplug stuff behaves better, many "rmmod" issues will also be going away. - Dave ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
