Re: [linux-usb-devel] Can't rmmod usbcore with very latest kernel (solved!)
I have just found out that the problem turned out to be that usbfs WAS mounted. This is what happened: 1) I tried booting as normal. At this stage usbfs got mounted, which I didn't notice. 2) I renamed /lib/modules/.../drivers/usb/ to usb-2, and rebooted. Since usbcore was not found, usbfs was not mounted. I really thought that usbcore couldn't be removed after ehci-hcd was inserter, but I cannot reproduce this. I'm really very sorry I wasted your time :-/ -- Regards, Christian Iversen --- 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
Re: [linux-usb-devel] Can't rmmod usbcore with very latest kernel
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-develm=110316031705757w=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
[linux-usb-devel] Can't rmmod usbcore with very latest kernel
I can't rmmod usbcore with latest (2.6.10-rc3-bk14). rmmod / modprobe -r usbcore gives FATAL: Module usbcore is in use.. rmmod -f usbcore gives the odd ERROR: Removing 'usbcore': Resource temporarily unavailable What's up here? Is the kernel trying to prevent me from shooting myself in the foot? If so, can I let it know that it's MY foot, and I want to take responsibility? :) There's nothing to see in dmesg, even with verbose logging. I sent David Brownell my dmesg on a (presumably?) unrelated matter, so he might be able to make heads and tails of this. -- Regards, Christian Iversen --- 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
Re: [linux-usb-devel] Can't rmmod usbcore with very latest kernel
On Tuesday 21 December 2004 11:12 am, Christian Iversen wrote: I can't rmmod usbcore with latest (2.6.10-rc3-bk14). rmmod / modprobe -r usbcore gives FATAL: Module usbcore is in use.. rmmod -f usbcore gives the odd ERROR: Removing 'usbcore': Resource temporarily unavailable What's up here? Hmm, if this is after you get that fatal error out of EHCI during init (which I've not had time to do much with; and it doesn't happen on any of my hardware) I suspect it's just that usbcore isn't cleaning up properly there. All the HCDs, and other USB drivers, need to be first idled, then removed; but the hub driver, at least, doesn't get cleaned up. - Dave --- 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
Re: [linux-usb-devel] Can't rmmod usbcore with very latest kernel
On Wednesday 22 December 2004 01:11, David Brownell wrote: On Tuesday 21 December 2004 11:12 am, Christian Iversen wrote: I can't rmmod usbcore with latest (2.6.10-rc3-bk14). rmmod / modprobe -r usbcore gives FATAL: Module usbcore is in use.. rmmod -f usbcore gives the odd ERROR: Removing 'usbcore': Resource temporarily unavailable What's up here? Hmm, if this is after you get that fatal error out of EHCI during init (which I've not had time to do much with; and it doesn't happen on any of my hardware) I suspect it's just that usbcore isn't cleaning up properly there. All the HCDs, and other USB drivers, need to be first idled, then removed; but the hub driver, at least, doesn't get cleaned up. You're right, I just noticed the correlation between these two events. Is this a problem with ehci-hcd, or usbcore? (who should I nag about this? :) -- Regards, Christian Iversen --- 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
Re: [linux-usb-devel] Can't rmmod usbcore with very latest kernel
On Tue, Dec 21, 2004 at 08:12:16PM +0100, Christian Iversen wrote: I can't rmmod usbcore with latest (2.6.10-rc3-bk14). rmmod / modprobe -r usbcore gives FATAL: Module usbcore is in use.. rmmod -f usbcore gives the odd ERROR: Removing 'usbcore': Resource temporarily unavailable Are you sure usbfs isn't mounted anywhere? If so, you will not be able to unload usbcore. thanks, greg k-h --- 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
Re: [linux-usb-devel] Can't rmmod usbcore with very latest kernel
On Wednesday 22 December 2004 02:18, you wrote: On Tue, Dec 21, 2004 at 08:12:16PM +0100, Christian Iversen wrote: I can't rmmod usbcore with latest (2.6.10-rc3-bk14). rmmod / modprobe -r usbcore gives FATAL: Module usbcore is in use.. rmmod -f usbcore gives the odd ERROR: Removing 'usbcore': Resource temporarily unavailable Are you sure usbfs isn't mounted anywhere? If so, you will not be able to unload usbcore. Yes, it's a problem with ehci-hcd when it dies with fatal error on my (presumably) buggy hardware. David Brownell is looking into it now. -- Regards, Christian Iversen --- 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
Re: [linux-usb-devel] Can't rmmod usbcore with very latest kernel
On Tue, 21 Dec 2004, David Brownell wrote: On Tuesday 21 December 2004 11:12 am, Christian Iversen wrote: I can't rmmod usbcore with latest (2.6.10-rc3-bk14). rmmod / modprobe -r usbcore gives FATAL: Module usbcore is in use.. rmmod -f usbcore gives the odd ERROR: Removing 'usbcore': Resource temporarily unavailable What's up here? Hmm, if this is after you get that fatal error out of EHCI during init (which I've not had time to do much with; and it doesn't happen on any of my hardware) I suspect it's just that usbcore isn't cleaning up properly there. All the HCDs, and other USB drivers, need to be first idled, then removed; but the hub driver, at least, doesn't get cleaned up. It would be nice to find out what part of the cleanup isn't happening right. Do you know at what point that fatal error occurs? Is it during probe? Can you post a short patch that will simulate the same effect? 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. 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
Re: [linux-usb-devel] Can't rmmod usbcore with very latest kernel
On Tuesday 21 December 2004 5:54 pm, Alan Stern wrote: On Tue, 21 Dec 2004, David Brownell wrote: Hmm, if this is after you get that fatal error out of EHCI during init (which I've not had time to do much with; and it doesn't happen on any of my hardware) I suspect it's just that usbcore isn't cleaning up properly there. All the HCDs, and other USB drivers, need to be first idled, then removed; but the hub driver, at least, doesn't get cleaned up. It would be nice to find out what part of the cleanup isn't happening right. 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, 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). 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. 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-develm=110316031705757w=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.) Do you know at what point that fatal error occurs? Is it during probe? Can you post a short patch that will simulate the same effect? Near the end of ehci_irq(), just mask STS_FATAL into the IRQ status mask before testing whether that's in the mask. That ought to do it. It happens after probe, sometime after the root hub has been enumerated and before the first real IRQ has been fully processed. 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! - Dave 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
