On Mon, 14 Mar 2005, Bernard Blackham wrote: > Not happy yet. Passing D0 to uhci suspend's method is the cause of > the issue (it doesn't handle it particularly well), and D0 is also > passed when PMSG_FREEZE is sent. So while it works for entering S3, > it fails in the same way when preparing for the atomic copy in S4. > > Hacking around the issue by always using D3hot should return it back > to the pre-drivermodel behaviour and mostly works. However at least > one person has reported that even doing this, uhci_hcd alone > suspends fine, but if both uhci_hcd and ehci_hcd are loaded, USB is > dead on resume until reloading both modules. I'm still digging > deeper and may need to enlist the help of linux-usb-devel... I'm seeing similar problems on my system, using the gregkh-2.6 kernel. The motherboard is a PIIX4 and the builtin UHCI controller doesn't support PCI PM. The following sequence of commands provokes the problem (with no USB devices attached): cd /sys/device/pci*/*7.2 # The UHCI controller's directory echo -n 3 >usb1/power/state # Suspend the root hub echo -n 3 >power/state # Suspend the controller echo -n 0 >power/state # Resume the controller (The log indicates at this point that it's resuming from D0.) echo -n 0 >usb1/power/state # Try to resume the root hub Now things go crazy. For some reason the controller is left in an unconfigured state, as revealed by lspci -vvb (no I/O mapping, IRQs not routed anywhere). I'm not sure if that happens before or after the final command. I'm also not sure if it's caused by the resume routines in hcd-pci.c or the resume routines in uhci-hcd.c. The whole suspend/resume support in uhci-hcd is due for a drastic overhaul. I've just done the work leading up to it; finishing it will take some time -- maybe a few weeks. I'll try running some more tests when there's a chance, and let you know what turns up. Alan Stern
