Wake-on-USB works with 2.6.32, fails with 2.6.34

depontius · Advocate Joined: 05 May 2004 Posts: 3526

I have a myth frontend machine which has been running happily for some time. In order to make it more "appliance-like" I have had the power button on the remote mapped to hibernate-ram, so it can turn back on faster. This worked reasonably well, though mythfrontend itself has had some problems working this way, but that's beyond the scope of this post.

The last kernel where wake-on-usb worked properly was in the gentoo-sources-2.6.32-r? series. I skipped 2.6.33 and moved directly to gentoo-sources-2.6.34-r?. Wake-on-usb does not work with the 2.6.34 series. Furthermore, the problem appears to be in the suspend portion, not the wake. I have an el-cheapo mceusb remote and receiver, and the receiver has a little red LED that flashes any time it receives a signal from the remote. So during normal operation, press a button on the remote, see the LED flash. With 2.6.32 and earlier, when the system is suspended, pressing the power button on the remote would make the LED on the receiver light, and it would stay lit until the system had wakened, then it would go out, and begin responding as-normal to further button presses. With 2.6.34, when the system is suspended, press the power button on the remote and the LED on the receiver stays dark. So this looks to me as if something in the suspend code has turned the USB port completely off, on its way down. What's ironic is that if I power the system off (/sbin/poweroff, not the switch on the power supply) the LED on the receiver still responds. So something specific was done here during suspend.

I'm willing to grant that perhaps I only had working suspend/wake with 2.6.32 and earlier only because of a bug, and now it's "fixed". But I don't think so. I'd like to track this down, and I believe that there is some way to intelligently go through the kernel patches that turned 2.6.32 into 2.6.33 then 2.6.34. Obviously going through every patch would be daunting, but it seems to me that this is a problem that has to be in both USB and Suspend (more probably ACPI) and there ought to be a way to intelligently reduce the set of patches I need to look at.

Is anyone familiar with this process, to help me on my way?

Incidentally, in another thread someone had wake-on-LAN quit working between 2.6.32 and 2.6.34, as well. They may be related.
_________________
.sigs waste space and bandwidth

BradN · Posted: Wed Oct 06, 2010 4:57 pm Post subject:

Try the latest unstable kernel if you haven't. If that doesn't fix, try to replicate the problem in vanilla-sources - if it exhibits the problem there and hasn't yet been fixed in the latest kernel.org kernel, you can perform a bisection test to determine the exact change that broke it (requires compiling and testing ~10 kernels and reporting whether they worked or not to narrow down the exact change involved, but it's an automated process through git to fetch the kernels to test). This lets you file a useful bug report and will almost ensure it gets fixed in future releases.

depontius · Advocate Joined: 05 May 2004 Posts: 3526

There's another problem here, and that is that LIRC is in the process of moving into the kernel, and parts of it are in-kernel in 2.6.35. That might solve my problems, but I don't think Gentoo has LIRC userspace that can work with the in-kernel, though I may be wrong on that. Anyway, there are such big changes that I've been reluctant to move to 2.6.35. I'm on the LIRC list, so maybe it's time to ask there about what I need to do. I've been thinking in terms of solving one problem at a time, but even now I've kind of shelved the suspend problems, so maybe moving to 2.6.35 will solve that, as a bonus.
_________________
.sigs waste space and bandwidth

aCOSwt · gentoo-sources-2.6.34-r?

depontius · Advocate Joined: 05 May 2004 Posts: 3526

I think that box is at 2.6.34-r10 or 2.6.34-r11. I built the new kernel this past Saturday, with whatever my server picked up as latest'n'greatest 2.6.34 when it rsync'ed in the wee hours of Saturday morning. That system isn't running at the moment - I just tried connecting. My mythbackend is at 2.6.35-gentoo-r7, but I'd purposely held the frontend machine back. Now that I think of it, I normally do service on my home machines on the weekend, so their portage trees will have the same timestamp. I see "gentoo-sources-2.6.34-r11". I'm able to "emerge -p" that kernel, so it's not hard masked.

So I guess the answer is 2.6.34-r11 for that machine.

I did a little other searching and found complaints about a similar phenomenon on Ubuntu, but they made it sound as if a fix got into the mainstream kernel about a month ago, in which case I should have had it by now. They list a patch, so tonight I'll compare my kernel source to the patch and see if it looks more like the source or the final. Maybe this patch will fix my problems, maybe it's unrelated.
_________________
.sigs waste space and bandwidth

depontius · Advocate Joined: 05 May 2004 Posts: 3526

Rats. On bugzilla it appeared easy to make an ebuild for the now-released, but not yet in portage lirc-0.8.7. In addition to being latest'n'greatest, it works with 2.6.35. So I made a local ebuild, and indeed it works with 2.6.34-r11. Then I build kernel 2.6.35-r9 and rebuilt lirc against that.

Still no-go. What's worse, on the one try I had time to make, eth0 didn't come back from suspend. So with 2.6.35 wake-on-usb still doesn't work, and eth0 doesn't wake properly. 0 for 2. Negative progress.

I've gone back to making the remote button power down instead of suspend. I can't turn on with the remote, and it takes longer to be ready from the front-panel switch, but at least it works.

Maybe my time would be better spent getting baselayout-2 and systemd working - for a faster boot.
_________________
.sigs waste space and bandwidth

Art Vandalay · Posted: Wed Jan 19, 2011 8:43 am Post subject:

Hi Depontius,

Were you ever able to resolve this problem?

Has this situation been resolved with the newer kernels? I am on 2.6.36-gentoo

I too are in a similar situation....ie I can put my desktop into S3 but can only wake via pushing the power button.

My motherboard is a Gigabyte X58A-UD5 and I was under the impression that wake-up via a USB event was not a feature of this board as it is not mentioned in the BIOS.
The BIOS and manual only mention wake on lan, and wake up via ps2 keyboard or mouse....btw, wake on lan works a treat.

But to my surprise when I boot into Windows 7 I can successfully wake the pc up via my usb mouse...and I can see that it remains powered on when the pc is in suspend to ram mode (S3).

Question: Does this mean I should theoretically be able to do this in gentoo as well, or is this some Windows trickery to get around the motherboard limitation?

Info as follows:

Art Vandalay · Posted: Sun Jan 23, 2011 3:02 am Post subject:

ok have made some progress.

i realised with my bios pressing ctrl+f1 at the main screen activates the advanced options and i can now see that 'wake s3 from usb device' is indeed enabled. why this option isn't visible by default is beyond me....anyway...

in my kernel under "Device Drivers" -> "USB Support" i had to enable "USB runtime power management" (ie USB_SUSPEND).

recompiled, rebooted, tried again...still no luck.

after some further research it looks like with the newer kernels an extra step is required.

for example to get my usb optical mouse to wake the pc....

depontius · Advocate Joined: 05 May 2004 Posts: 3526

I never thought to go into /sys/devices to look for the wakeup stuff. The system is currently booted to 2.6.32, and I just walked the appropriate /sys path, and indeed wakeup is enabled. Next to boot 2.6.36 and check the same thing.

I don't know if our problems are relevant to each other. Yours seems to be more related to certain devices not waking properly - mine seems to be related to kernel levels. Have you tried your wake experiments with a 2.6.32-series kernel?

Another thing to look at would be USB 2 vs USB 1.1. The same jack gets fielded by two different drivers and comes out on two different devices, depending on which USB level it is. I have separate ACPI wakeup entries for USB 2 vs USB 1.1 - which reminds me, I need to re-borrow the smart-hub from a friend at work and experiment again. His hub switches things to USB 2 - so I can plug in my USB 1.1 mceusb IR receiver, and it will send USB 2 events to the computer.
_________________
.sigs waste space and bandwidth

Saviq · n00b Joined: 31 Mar 2011 Posts: 3

@depontius have you solved your issue in the end?

I have struggled with remote wakeup in my Scaleo E (it has mceusb built in) for a long time now. And this thread helped a _lot_. I got it working at last.

Here's an oneliner that found me all the wakeup-enabled usb devs:

depontius · Advocate Joined: 05 May 2004 Posts: 3526

I got some more information about this earlier this week from the LIRC mailing list. It turns out that they made changes to the wakeup mechanism and how USB interacts with it between 2.6.32 and 2.6.33. As near as I can figure, "/proc/acpi/wakeup" only gets the USB channel ready to wake the system. At least when I look in "/sys/devices/pci/pcixxxx/power/wakeup" I see what was done in "/proc/acpi/wakeup" mirrored there. But it looks like it's also necessary to get the USB device itself ready to wake the system, in "/sys/bus/usb/xxxxx/power/wakeup". The other night I enabled the latter path as well as the usual one, and was able to sleep and wake the system with the remote control.

I need to carefully look at your udev script, but what I think I'd really like is a udev script that waits for its "mceusb" event, then enables that device and the USB port that it's plugged into.

I suspect for the moment I'm just going to kludge together a local.start script to hard-enable the right device. I need to get to a newer kernel, so I can migrate LIRC from the out-of-kernel mceusb to the newer in-kernel mceusb.
_________________
.sigs waste space and bandwidth

Saviq · n00b Joined: 31 Mar 2011 Posts: 3

depontius · Advocate Joined: 05 May 2004 Posts: 3526

Rules tweaked and installed, we'll see what happens.

Actually, I've got logger statements in the enable/disable scripts, which I put in /usr/local/sbin, and I exit right after. Once I've seen what the log says, I'll remove the exit statements and let her fly.

Then I'll try going back to 2.6.37.
Then I'll look at migrating to the in-kernel lirc drivers.

EDIT
On a quick first-try, I got no events logged upon a reboot. Should I be expecting udev events when I'm still using the out-of-kernel lirc drivers, or will those events only happen once I convert to in-kernel drivers? For the first attempt, I stuck my logger statement before checking to see if action=add, figuring more verbosity would help, or at least enlighten.
_________________
.sigs waste space and bandwidth

Saviq · n00b Joined: 31 Mar 2011 Posts: 3

Art Vandalay · Posted: Wed Dec 28, 2011 1:40 pm Post subject:

now that i am on holidays i revisited this topic...couldn't end the year with this not being solved!

ended up ditching my dvico ir receiver and getting a cheap mce usb receiver (model 1039) off ebay which has solved the issue, as they are capable of waking a system from s3

i created the following udev rule:

# enable wake from S3 for MCE USB device 0471:0815
SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="0471", ENV{ID_MODEL_ID}=="0815" RUN+="/bin/sh -c 'echo enabled > /sys$env{DEVPATH}/power/wakeup'"

wake up from the remote now works perfect....didn't happen overnight, but it did happen

thanks guys
_________________
I might not have morals...but at least I have standards

depontius · Advocate Joined: 05 May 2004 Posts: 3526

I recently moved my mythfrontend machine from 2.6.38 to 3.2.1, and moved from lirc-0.8.7. to lirc-0.9.0, and from lirc_mceusb to devinput, all in the same process. (Unfortunately it was practically impossible to break this migration into pieces.)

I lost wake-on-usb in the process, though somehow I did keep power to the USB receiver in the process. The "receive" light on the receiver would come on when I pressed the power button on the remote, then stay on. Then I needed to use the front-panel power button to wake the system, and once it woke the "receive" light would go off, and all would be well.

I never did implement the udev script mentioned above. But in the spirit of that script I went through the whole device chain and enabled power/wakeup every step of the way. I also enabled power/wakeup on the pci devices where the usb is attached, just for good measure.

I have wake-on-usb back.

On general principle, I really need to go back and study the udev script above, and do that on my mythfrontend instead of my hard-coded enables. There are other things I'd like to do in a hardware-event-driven way, and this is the start point.
_________________
.sigs waste space and bandwidth