On Sun, 16 May 2010, Terence wrote: > I'm having a related problem. For a home theater PC, I have a gyration remote > (which registers as a USB mouse & keyboard). It supports remote wakeup, but I'm > having trouble getting it working reliably with S3. > > I first verify that S3 works fine. remote wakeup isn't enabled by default, so I > suspend to S3, then manually wakeup the system by pressing the power button > (this is on an Acer Aspire Revo 1600). Everything works fine, the system goes > into suspend as expected and wakes up when the power button is pressed. > > I then fresh reboot and enable remote wakeup via "echo USB0 > /proc/acpi/wakeup" > && "echo USB2 > /proc/acpi/wakeup", then "cat /proc/acpi/wakeup" to verify the > settings took. I've also verified various USB devices under > /sys/bus/usb/devices/ have wakeup enabled. The USB wakeup settings are controlled by /sys/bus/usb/devices/.../power/wakeup, not by entries in /proc/acpi/wakeup. > I then suspend to S3, which works fine, and then press a button on the remote > and the system wakes up fine. But after that first cycle, any subsequent attempt > to suspend will suspend and automatically resume. > > > hmm, I originally thought this was related to the gyration remote control, but I > tried rerunning some experiments to provide accurate data and it now appears any > USB device plugged in results in automatic wakeup if I try to suspend. In > contrast, I can suspend just fine if I unplug all USB devices. I had also seen > the "S3 works only on first try" previously, but I'm unable to reproduce that > right now, the system always wakes up immediately. > > I was previously suspicious that whatever triggered the wakeup was not being > cleared. That would allow the first S3 cycle to work fine, but then wakeup was > continually asserted and would keep another S3 cycle from working. I realize my > data seems a little sketchy in my retests. I'm not sure if I've changed > something or just missing a step in my previous reproductions. > > In any case, is there a way to identify what triggered a wakeup? It might show up in a "lspci -vv" listing. But in general, no -- AFAIK the kernel doesn't have any debugging output to identify the source of a wakeup. If your kernel build ehci-hcd, uhci-hcd, and ohci-hcd as modules, you could try removing each one of them before suspending to see if it makes any difference. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
