On Sat, 8 Jan 2005, Oliver Neukum wrote: > Am Samstag, 8. Januar 2005 18:52 schrieb Alan Stern: > > > Secondly, the startup kernel gets control of the machine. If the HCD is > > compiled in, then it will grab the HC and reset it. (I would like to know > > how to tell whether that step can be avoided. There's a further > > You can't. You only know after initialisation whether there is an image > to read back.
Yes, you can't tell whether or not the current kernel will be overlaid. But maybe you can tell whether or not the controller needs to be reset. At this point, my best guess is that a reset is needed only if it's clear that the BIOS _was_ in control of the HC. > Upon further reflection, in a statically compiled driver you know > you are taking over from yourself, already at compile time. That's consistent with my heuristic. I do want to avoid doing a reset if it's not necessary, because a reset will break all existing connections. That's bad for things like storage devices with mounted filesystems... > [..] > > If the HCD was build as a module then it may not be loaded at all while > > the startup kernel is running. I forget the details of how this works; > > can the module be loaded from an initrd or equivalent before the image is > > restored? > > IIRC you can't. That agrees with my vague memories. > > Certainly the current code in the driver doesn't do this correctly. In > > fact, it pretty much ignores the whole issue. Still, I would expect it to > > work in your computer. > > It does, if ehci_hcd isn't loaded. Even with ehci-hcd loaded, I would expect that uhci-hcd would see the mouse disconnect, and that ehci-hcd would see a new connection and would pass control of the port back to uhci-hcd. Clearly that's not happening; I'm going to have go through and study your logs carefully. Maybe part of the problem is that uhci-hcd is too eager to suspend itself when no ports are connected. It would be nice to know what khubd was doing during the time while you kept getting all the suspend/resume pairs from uhci-hcd and all the EILSEQ errors from hidcore. Was khubd stuck waiting for an event that was never delivered because of problems with the root hub status URB? Or was it stuck somewhere else? Time to go look at those logs again... Alan Stern ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
