On Thu, 9 Aug 2007, Zephaniah E. Hull wrote: > Urgh, I definitely need some sleep, yes, it's a &&.
> Which, from the debugging statements from previous failed runs, we have > something odder. > > reset_resume == 0, udev->state == USB_STATE_CONFIGURED. > > This is an even more bizarre state then I thought. After you get up :-), check udev->state at the end of usb_suspend_device(). It should be USB_STATE_SUSPENDED, and nothing should change it until usb_resume_device() runs. Are you maybe seeing ohci_rh_resume() get called twice in a row? > > Nothing should. You might want to add a debugging printk to > > ohci_pci_resume() or prepare_for_handover() to see what the value is at > > the start of the resume. Maybe the firmware sets it incorrectly before > > the driver does anything. > > Perhaps, we seem to have a lot of very odd state at the time that we try > to resume the OHCI root hub. Agreed. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
