> > No, a code inspection shook out the fact that it didn't even > > play by the 2.4 rules, which require HCDs to clean up their > > device state when bus->op->deallocate() is called. > > That was never a rule for 2.4. Reference counting takes care of making > sure things work correctly after deallocate().
What can I say but "news to me". It clearly did not do that in more than a few cases I've had to work through. Since I've had to rely on deallocate() doing something sensible, I'm going to have to believe my own experience. I can't count experience with UHCI's NOP there as relevant. > > Note that Andries' BUG() is (a) different from the one I noticed > > uhci.c might trigger, and is even in a different source file; also > > (b) followed several other USB problems, one of which is IMO > > likely causing his BUG(). > > Huh? Care to explain? (a) is in usb.c <-- source ... and see what I wrote (b) is in usb.h <-- header ... and see his post of this AM > The BUG() Andries' posted about was the result of UHCI finishing up with a > QH after usb_disconnect(). Maybe ... but if so, you've seen a LOT more information from him than I've seen. I saw a partial stack trace, and /proc/bus/usb/devices data that (by his statements) was clearly showing symptoms of illness even when his system wasn't (infrequently) oopsing. > > Do you mean uhci_free_dev()? The NOP? Remember that > > method must be called when it can sleep ... > > Looking now, I don't even see why bus->op->deallocate() is necessary. > OHCI doesn't even appear to need it. Look harder ... :) There's state kept around that needs to be freed. For example the EDs (corresponding to a QH). In some cases, sleeping is necessary to make sure they're fully unlinked "now". - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
