On Tue, 21 Dec 2004, David Brownell wrote: > Cleanup that's never happened right. Basically what's needed is > to have the hub driver (a) stop the root hub timer, which is simple > enough,
That happens when the status URB is dequeued, so when the root hub is disconnected during usb_hcd_pci_remove, assuming it hasn't happened already. (My recent patch for root-hub polling changes that, and in fact I forgot to add code to stop the timer.) It shouldn't cause a blockage during rmmod. > then (b) invoke hcd->stop(), which isn't. The stop() has > to be from khubd otherwise deadlocks happen; for a while, keventd > was calling that (and I saw deadlocks). That also is supposed to happen in usb_hcd_pci_remove, although it runs in the rmmod context rather than the khubd context. Again, I don't see how failing to do it when the HC dies would cause rmmod to hang. Unless it's that deadlock you mention? > Maybe a quick'n'dirty fix > is just to clear the config flag register as well as reset EHCI, > and then let "rmmod" do the stop(). That'd defer any disconnects > till very late, though. > > That is, there are two separate problems. That cleanup after an > "hc died" fault has been a longstanding -- but rare -- problem. Yes indeed. It's a loose end that needs fixing, along with root-hub resume processing. Neither one has seemed important enough to worry much about, given all the other things still to do. > But actually needing it much at all is newish, and seems to have > been needed more often (EHCI only) starting with 2.6.6 or so, or > 2.6.7, or 2.6.8 depending on who reports it. And I didn't notice > any particularly relevant EHCI changes in those kernels either! > > One VT6202 version of the failure is suggestive too: > > http://marc.theaimsgroup.com/?l=linux-usb-devel&m=110316031705757&w=2 > > Because that chip wasn't reporting that it could switch port > power, yet it went and disabled the power on several ports. > And enabling the "should be a NOP" power switch logic seemed > to make a difference. (The current code reports "ganged" > power switching, which according to the EHCI spec is wrong. > EHCI should do per-port switching, or none at all.) I don't know what to make of that. But it's certainly true that because fatal HCD errors have been so rare up 'til now, the code has not been thoroughly exercized and debugged. > > I will spend some time this week redoing the bugfix and cleanup parts of > > the as424b-as426b patches, without the bus glue changes. Maybe that will > > make a difference. > > Hold off on that a bit yet. I may yet be persuaded that your > current patches are just fine; like I said, I just wanted a > chance to think about them properly! Okay, I'll keep that in limbo for the time being. Alan Stern ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
