On Sat, 8 Jan 2005, Oliver Neukum wrote: > > boot > > swsusp suspend > > SWSUSP MESSAGES AFTER IMAGE WAS WRITTEN > > (RE)BOOT > > SWSUSP MESSAGES SWITCHING TO OLD IMAGE > > swsusp resume > > > > I've certainly found cases where the the "MISSING LOG DATA" had some > > information that was essential to figuring things out. But then, it's
Yes indeed. Maybe what we're missing is crucial. > If the mouse is detected by the first sacrifical incarnation, the handover > is not to blame, is it? I doubt that's happening in this case. Since ehci-hcd and uhci-hcd are both modules, the boot kernel won't load them. As far as the most recent test (CONFIG_USB_SUSPEND not set), the log doesn't contain enough information to tell where the failure occurred. It's clear that khubd isn't following through on the disconnect message from uhci-hcd, but it's not clear why. Is the status URB timer routine not doing its job? Or is khubd getting hung up somewhere? Oliver, would you like to try adding some debugging lines to rh_report_status() in core/hcd.c? It gets called four times per second for each HC, so only print out messages for exceptional cases: URB already unlinked, urb->dev->state not equal to USB_STATE_CONFIGURED, or length > 0. Maybe use a static counter to limit the total number of messages printed. Also it might help to see the stack trace for khubd before you replug the mouse or remove any modules, as well as the uhci/0000:00:1d.0 debugging file. 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
