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

## depontius

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.

----------

## BradN

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

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.

----------

## aCOSwt

 *depontius wrote:*   

> gentoo-sources-2.6.34-r?

 

r?, r what ?

 *depontius wrote:*   

> I've been reluctant to move to 2.6.35

 

+1

There have been several problems reported by many with USB HID devices and 2.6.34-r6

There was actually a bug that is actually solved with 2.6.34 >= r7

Considering several security patches commited since,

If r? == r6 then I would advise you to give r10 a chance.

----------

## depontius

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.

----------

## depontius

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.

----------

## Art Vandalay

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:

 *Quote:*   

> 
> 
> telesto jk # acpitool -w   
> 
>    Device       S-state   Status   Sysfs node
> ...

 

and system setup as follows:

 *Quote:*   

> 
> 
> Portage 2.1.9.32 (default/linux/amd64/10.0/desktop/kde, gcc-4.4.5, glibc-2.12.2-r0, 2.6.36-gentoo x86_64)
> 
> =================================================================
> ...

 

I'd love to get this working as I have a similar motherboard in my lounge room that is a frontend mythbox,  and hence, would like to be able to wake the frontend up via my usb remote receiver.

Thanks

----------

## Art Vandalay

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....

 *Quote:*   

> 
> 
> # dmesg|grep -i optical
> 
> [   10.610913] usb 8-1: Product: Microsoft Wheel Mouse OpticalÂ®
> ...

 

tells me the usb port and pci slot being used

 *Quote:*   

> # cat /sys/devices/pci0000\:00/0000\:00\:1d.2/usb8/8-1/power/wakeup
> 
> disabled
> 
> 

 

now enabling the device directly...

 *Quote:*   

> 
> 
> # echo enabled > /sys/devices/pci0000\:00/0000\:00\:1d.2/usb8/8-1/power/wakeup
> 
> 

 

now we have 

 *Quote:*   

> 
> 
> # cat /sys/devices/pci0000\:00/0000\:00\:1d.2/usb8/8-1/power/wakeup
> 
> enabled
> ...

 

now when i sleep the pc i can wake it up with my usb device...ie the mouse.

going through the same procedure for my usb cordless keyboard i can now wake up my mythtv frontend in the front room   :Smile: 

but i have had no success with my usb ir receiver...when i cat the wakeup file there is no enabled or disabled....

which leads me to my next question...are all USB IR Receivers made equal? ie should all be able to wake a pc from s3 or is it only certain usb IR receivers that have this functionality??

I am using a dvico IR receiver:

 *Quote:*   

> 
> 
> # dmesg|grep -i dvico
> 
> [    3.243469] usb 3-1: Product: DVICO USB HID Remocon V1.00
> ...

 

Would love to hear from someone using a similar device or had some experience with this stuff....

----------

## depontius

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.

----------

## Saviq

@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:

```
$for i in `find /sys/devices/pci* -name wakeup | grep usb`; do if [ -n "$(cat $i)" ]; then echo -n "$i - "; echo -n "$(cat $(dirname `dirname $i`)/product | tr -d "\n"): "; cat $i; fi; done
```

On a freshly booted system, here's how it looks here (ignore the missing product file):

```
/sys/devices/pci0000:00/0000:00:1d.0/usb2/power/wakeup - UHCI Host Controller: enabled

/sys/devices/pci0000:00/0000:00:1d.1/usb3/power/wakeup - UHCI Host Controller: enabled

/sys/devices/pci0000:00/0000:00:1d.2/usb4/power/wakeup - UHCI Host Controller: enabled

/sys/devices/pci0000:00/0000:00:1d.2/usb4/4-2/power/wakeup - eHome Infrared Transceiver: disabled

/sys/devices/pci0000:00/0000:00:1d.3/usb5/power/wakeup - UHCI Host Controller: enabled

/sys/devices/pci0000:00/0000:00:1d.7/usb1/power/wakeup - EHCI Host Controller: enabled

/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-4/power/wakeup - cat: /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-4/product: No such file or directory

: disabled

/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.4/power/wakeup - 2.4G USB RF KeyBoard: enabled

```

Here's my /proc/acpi/wakeup:

```
Device  S-state   Status   Sysfs node

PCI0      S5    *disabled  no-bus:pci0000:00

PEX0      S5    *disabled

PEX1      S5    *disabled

PEX2      S5    *disabled

PEX3      S5    *disabled

HUB0      S5    *disabled  pci:0000:00:1e.0

UAR1      S5    *disabled  pnp:00:07

UAR2      S5    *disabled  pnp:00:08

USB0      S3    *disabled  pci:0000:00:1d.0

USB1      S3    *disabled  pci:0000:00:1d.1

USB2      S3    *disabled  pci:0000:00:1d.2

USB3      S3    *disabled   pci:0000:00:1d.3

USBE      S3    *disabled  pci:0000:00:1d.7

AC97      S5    *disabled

AZAL      S5    *disabled  pci:0000:00:1b.0

```

After a quick:

```
$ echo "enabled" > /sys/devices/pci0000:00/0000:00:1d.2/usb4/4-2/power/wakeup

$ echo "USB2" > /proc/acpi/wakeup

```

Remote wakeup works again! What's weird is that regardless of /proc/acpi/wakeup it wakes up off of the RF keyboard (which is annoying due to its trackball being too sensitive...), but I can disable it in sysfs.

I'll report back if I can get a udev rule to handle that.

EDIT:

OK, I have it working, here're two simple scripts:

enable_wakeup.sh:

```
#!/bin/bash

[ "${ACTION}" != "add" ] && exit

ACPIWAKE=/proc/acpi/wakeup

PCI=$(echo ${DEVPATH} | cut -d/ -f4)

ACPIDEV=$(cat /proc/acpi/wakeup | grep $PCI | awk '{ print $1 }')

STATUS=$(cat /proc/acpi/wakeup | grep $ACPIDEV | awk '{ print $3 }')

[ "${STATUS}" != "*enabled" ] && echo ${ACPIDEV} > ${ACPIWAKE}

TMP=${DEVPATH}

# enable wakeup on the whole chain

while true; do

        WAKE=/sys${TMP}/power/wakeup

        [ -f "${WAKE}" -a -n "$(cat ${WAKE})" ] && echo "enabled" > ${WAKE}

        TMP=${TMP%/*}

        [ $TMP == "/devices" ] && break

done

```

... and disable_wakeup.sh:

```
#!/bin/bash

[ "${ACTION}" != "add" ] && exit

TMP=${DEVPATH}

# disable wakeup on the deepest possible entry

while true; do

        WAKE=/sys${TMP}/power/wakeup

        [ -f "${WAKE}" -a -n "$(cat ${WAKE})" ] && echo "disabled" > ${WAKE} && break

        TMP=${TMP%/*}

done

```

A simple /etc/udev/rules.d/80-wakeup.rules:

```
# enable wakeup from mceusb

SUBSYSTEM=="usb", ATTR{idVendor}=="1509", ATTR{idProduct}=="9242", RUN+="/usr/local/bin/enable_wakeup.sh"

# disable wakeup from keyboard

SUBSYSTEM=="usb", ATTR{idVendor}=="05af", ATTR{idProduct}=="0319", RUN+="/usr/local/bin/disable_wakeup.sh"

```

Tweak to taste (remember to chmod +x the scripts and tweak the RUN assignments to match where the path where you put them) and you're off  :Smile: 

----------

## depontius

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.

----------

## Saviq

 *depontius wrote:*   

> 
> 
> 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.
> 
> 

 

What it does is, whenever my receiver gets loaded (that's the ATTR{idVendor}=="1509", ATTR{idProduct}=="9242" - these might be different for you) it iterates back from the device itself and enables every power/wakeup it finds disabled. Then it enables the bus in /proc/acpi/wakeup. I think I was unable to wake without explicitly enabling it there.

As for disabling - it only disables the furthest possible entry, so as not to disable e.g. other devices on the same bus.

----------

## depontius

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.

----------

## Saviq

 *depontius wrote:*   

> 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.

 

It doesn't rely on any lirc drivers. You can verify that the scripts will get run with 

```
$ udevadm test /sys/bus/usb/devices/3-2
```

 where "3-2" is your receiver device. You should see a line like 

```
udevadm_test: run: '/usr/local/bin/enable_wakeup.sh'
```

 That ensures that the device triggers the rule you've added.

----------

## Art Vandalay

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  :Smile: 

thanks guys

----------

## depontius

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.

----------

