On Thu, Apr 18, 2002, David Brownell <[EMAIL PROTECTED]> wrote: > > > 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.
Clearly? It's always worked for me and it works for the rest of the kernel too. > 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. I don't know what to tell you then. Your experience appears to be directly contradictory to the rest of the kernel. > > > 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 You really need to take a couple of days off and revisit this. You are clearly missing a couple of significant points in this discussion. > > 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. Actually, I haven't seen any more information from him than you have. Why do you think I have? It's pretty clear to see what the bug is given his call trace, knowledge of how uhci.c works and the changes you've made to the reference counting in 2.5. > > > 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". But if you used reference counting like it was intended that wouldn't be a problem. Seriously, take a look at the rest of the kernel. You're just making things harder on yourself than they need to be. JE _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
