I have a mythfrontend "appliance" and have mapped the power button on the remote control to put the system to sleep. I have set the system to wake-on-USB, so that when the system is sleeping and I press the power button on the remote control, the system wakes. For all releases I've tested of sys-kernel/gentoo-sources-2.6.32-r* and earlier this works. I have not tested sys-kernel/gentoo-sources-2.6.33, but for anything after that (2.6.34, 2.6.35, and 2.6.36) it fails. The system goes to sleep properly, but the will not wake with USB. Furthermore, it appears that there is no power delivered to the USB system. Normally when a button on the remote control is pressed, an LED lights on the IR receiver, even when the system is sleeping. But after going to sleep using kernel-2.6.34+ that LED never lights. The power button on the case will wake the system with any kernel level, and I've verified that it is waking, not rebooting. The only variable in this is the kernel level. All else has remained the same. The kernel configuration is a similar as I can make it. Reproducible: Always Steps to Reproduce: 1. The standard gentoo-sources kernel is built with sleep/suspend configured in. 2. I have enabled wake on "USB15" in /proc/acpi/wake 3. I have installed and configured LIRC, including mapping the power button to run a suspend script. 4. Put the system to sleep with the power button on the remote control. 5. Try to wake the system with the power button on the remote control. Actual Results: With kernel-2.6.34 or later, nothing happens, the system does not wake. The light on the IR receiver does not flash, indicating that it may not be powered. Expected Results: The system should wake, and with kernel-2.6.32 or earlier, it does. The light on the IR receiver flashes upon button presses. /proc/acpi/wake: Device S-state Status Sysfs node UAR1 S4 disabled pnp:00:0a NSMB S4 disabled pci:0000:00:01.1 USB0 S4 disabled pci:0000:00:02.0 USB2 S3 disabled pci:0000:00:02.1 US15 S4 enabled pci:0000:00:04.0 US12 S3 disabled pci:0000:00:04.1 NMAC S5 disabled pci:0000:00:0a.0 P0P1 S4 disabled pci:0000:00:08.0 HDAC S4 disabled pci:0000:00:07.0 BR10 S4 disabled pci:0000:00:0b.0 BR11 S4 disabled pci:0000:00:0c.0
anything in dmesg? If so, can we compare a working dmesg to a non-working one? Have you tried a vanilla kernel?
(In reply to comment #1) > anything in dmesg? If so, can we compare a working dmesg to a non-working one? > > Have you tried a vanilla kernel? > I can give both a try. This gives a bit of a matrix to cook up, but not tough. I'd been hoping that at some point sleep/wake would "just work" again, but finally seeing it fail on 2.6.36, and I guess it's time to dig.
Created attachment 259958 [details] dmesg.2.6.32-gentoo-r24.postboot
Created attachment 259959 [details] dmesg.2.6.32-gentoo-r24.postwake
Created attachment 259961 [details] dmesg.2.6.36.2.postboot
Created attachment 259963 [details] dmesg.2.6.36.2.postwake
Created attachment 259964 [details] dmesg.2.6.36-gentoo-r6.postboot
Created attachment 259966 [details] dmesg.2.6.36-gentoo-r6.postwake
Created attachment 259968 [details] dmesg.2.6.36-gentoo-r6.postwakeA For the "2.6.36-gentoo-r6.postwakeA" run I enabled ACPI wakup for the USB 2.0 port associated with the USB 1.1 port I am using to wake the system. The MCEUSB IR receiver I use simply IS a USB 1.1 device, and only hooks up that way unless I send it through a smart USB 2 hub, first.
(In reply to comment #1) > anything in dmesg? If so, can we compare a working dmesg to a non-working one? > > Have you tried a vanilla kernel? > I lost my first reply to your request when I started adding the dmesg attachments, so I'm retyping. Sorry for taking so long to get back to you - there's been a bug ripping its way through the family since New Year's Eve, and I'm still not back 100%. But I'm back enough and have some time now. I've run kernels gentoo-sources-2.6.32-r* and all suspend/wake successfully. I've also run vanilla-sources-2.6.36.2 and gentoo-sources-2.6.36-r6 and both fail to wake, and I suspect it's because they've turned the USB device off on their way to suspend. I've attached dmesg listings both post-boot and post-wake for each kernel. I made one extra attempt, enabling the system to wake on US15 as well as the normal US12. (Names from my /proc/acpi/wake previously posted.) US15 is the USB 2.0 port associated with the same hardware that shows up for USB 1.1 as US12. I figured it was worth a try, but no dice.
It's been awhile, can you test with gentoo-sources-2.6.38 ?
(In reply to comment #11) > It's been awhile, can you test with gentoo-sources-2.6.38 ? I'll see what I can do this weekend. I've done a little searching, and it appears that nvidia-drivers may have problems with 2.6.38, and I may have to wait until they've released their patched drivers. (I was rather expecting this kind of thing, nVidia is having to do some work on their driver for just about every new kernel or X version, which is why I was searching.) I also suspect I'm going to have lirc problems post 2.6.37, but at the very least I can run this system with keyboard and mouse. I've also got openafs installed, and I already know its kernel module won't build against 2.6.38, but I can do without that, too. The kicker is that it's only got tv-out connected, so I can't do without nvidia-drivers. It seems that the ioremap errors may not be universal, so I'll just have to try. Any comment about the information I provided per your last request? Presuming I get 2.6.38 + nvidia running, is there anything specific you'd like to see?
I built 2.6.38-gentoo right after you made the suggestion, but was unable to test it until yesterday. (After finally getting the tape and mud done in the basement bathroom.) When I built the kernel, "module-rebuild rebuilt" went OK, except OpenAFS, which I knew would fail. Actually running 2.6.38 was mixed. On my first try, I got a video hang running TV through mythfrontend. Later on when booted to 2.6.38 my wife and daughter started watching something while I was looking the other way. Their video showed just fine. Some people have reported problem with nvidia-drivers and 2.6.38, so this was not a surprise, either. No change on waking. With 2.6.38 I still can't use USB to wake from suspend. On the suggestion from someone in the forum, I looked at sys/devices/pci/pcixxxxx/power/wakeup, and indeed it is "enabled", just like in /proc/acpi/wakeup.
Can you please file a bug at http://bugzilla.kernel.org and post the url back here?
(In reply to comment #14) > Can you please file a bug at http://bugzilla.kernel.org and post the url back > here? It's not a bug - I finally chased it down night before last, and have been trying to find time to post back here, and a few other places. It's a "documentation issue". Between 2.6.32 and 2.6.33 something in the USB wake architecture was changed. I get the impression that "/proc/acpi/wakeup" is deprecated, though that doesn't square with my experiences. In short, doing the same old thing to "/proc/acpi/wakeup" only enables the USB channel to wake the system. It no longer enables the specific device. In order to enable the device, I had to go into "/sys/bus/usb/devices/<info-at-home>/power/wakeup" and enable that, as well. Once I did that, I was able to suspend and wake my system with 2.6.38. I still don't know if "/proc/acpi/wakeup" will continue to be as functional is it is now, and only need supplementing on the USB device, or if it's going to evaporate too, leaving only the "/sys" interface for both. Nor do I know how to do this in a robust manner. Someone gave me a udev script, but I found nothing in that script tying it to "mceusb" and I'm not even sure if it could find the channel that the device was connected to. In the long term I need some "udev magic" here, so that when "mceusb" comes online both it and the USB channel it's plugged into can be enabled for wakeup - even if other USB devices are plugged in, changing all of the names. One other complication here is that LIRC is deprecating it's out-of-kernel drives, in favor of the in-kernel drivers adde with 2.6.36 or so. Without wakeup, I couldn't migrate past 2.6.32, therefore I couldn't get to the in-kernel drivers. I've had some occasional nVidia problems with 2.6.38, so I think I'm going to move my MythMachine to 2.7.37-r*, kludge the mceusb enable issue, and then start my migration to the in-kernel drivers. Hopefully in the long run this can get done cleanly. Good documentation would help. I can't call this [solved], but it sure has mutated. Here's a link to some discussion of this kind of problem on the USB list: http://comments.gmane.org/gmane.linux.usb.general/32115
I'm resolving this as there is not much left for us to do here.
