Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#19566 - [kernel26] 2.6.33.4-1 breaks wakeup from suspend with IR remote on USB port

Attached to Project: Arch Linux
Opened by Michael Zanetti (mzanetti) - Sunday, 23 May 2010, 14:02 GMT
Last edited by Dan McGee (toofishes) - Monday, 07 March 2011, 19:09 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
I use a eHome IR receiver with a MCE remote. By enabling wakeup for USB0 in /proc/acpi/wakeup I can use the remote to wake up the system from S3 suspend. This works flawlessly with kernel26-2.6.33.3-2 but has stopped working with the upgrade to 2.6.33.4-1. After a downgrade it works fine again.

Please note that wakeup using my USB keyboard (which has an external power source) works fine also with 2.6.33.4. Its just the IR receiver that has stopped working. It seems the new kernel is taking away the power supply for the USB receiver as also the LED doesn't flash any more on button presses while it does with older kernels.

Additional info:
* package version(s)
broken with 2.6.33.4-1
working with 2.6.33.3-2

* config and/or log files etc.
no config files required

* Steps to reproduce:
- attach IR receiver to a primary USB port.
- enable wakeup using:

echo USB0 > /proc/acpi/wakeup
echo USB2 > /proc/acpi/wakeup

- after enabling, it should show this:

# cat /proc/acpi/wakeup
Device S-state Status Sysfs node
SMB0 S4 disabled pci:0000:00:03.2
USB0 S4 enabled pci:0000:00:04.0
USB2 S4 enabled pci:0000:00:04.1
US15 S4 disabled pci:0000:00:06.0
US12 S4 disabled pci:0000:00:06.1
NMAC S5 disabled pci:0000:00:0a.0
PBB0 S4 disabled pci:0000:00:09.0
HDAC S4 disabled pci:0000:00:08.0
XVR0 S4 disabled pci:0000:00:0c.0
XVR1 S4 disabled
P0P5 S4 disabled
P0P6 S4 disabled pci:0000:00:15.0
P0P7 S4 disabled pci:0000:00:16.0
P0P8 S4 disabled pci:0000:00:17.0
P0P9 S4 disabled pci:0000:00:18.0
PWRB S4 *enabled

- put the system to S3 suspend. no matter if using pm-suspend, s2ram, solid-powermanagement or something else.
- wake the system up using the infrared remote. Doesn't work with 2.6.33.4.

* I'm willing to test packages or patches if you don't have the appropriate hardware around.
This task depends upon

Closed by  Dan McGee (toofishes)
Monday, 07 March 2011, 19:09 GMT
Reason for closing:  Upstream
Additional comments about closing:  "Fixed" upstream.
Comment by Tobias Powalowski (tpowa) - Sunday, 30 May 2010, 08:21 GMT
Please try .34 kernel if this is already solved.
Comment by Mathias Andersson (Wraul) - Sunday, 30 May 2010, 09:17 GMT
I'm also experiencing this, see my thread at http://bbs.archlinux.org/viewtopic.php?id=97998
According to the reply in that thread there has been a change in how usb remote wakeup is handled.
It appears that the driver now needs to request wakeup functionality.
Comment by Michael Zanetti (mzanetti) - Sunday, 30 May 2010, 18:49 GMT
I have tried .34 from testing. Same issue there.
Comment by Kimmo (Dehir) - Sunday, 27 June 2010, 07:44 GMT
Confirming similar bug with 2.6.34 . Wont wake up on suspend state by pressing the power button. Normally woke up, wont accept either reset. So only solution for me is to power down whole machine and power up again.
Comment by Michael Zanetti (mzanetti) - Sunday, 27 June 2010, 10:40 GMT
Kimmo: If you are talking about the Power button on the computers enclosure, this is a different bug. Wakeup from suspend works just fine for me using the machines power button or a keyboard. This bug is about the power button on infrared remote controls using an eHome IR Receiver attached to USB. If you are also having problems with a IR remote, welcome on board :)

Mathias: Did you find a workaround for the problem? Perhaps writing something to sysfs manually could do the stuff thats missing in the driver?

It seems this issue is because of a change in the kernel requiring lirc_mceusb to do some additional stuff. So maybe this bug belongs rather to lirc than to the kernel? On the other hand, IMHO waking up from suspend using the remote should also work without an lirc setup just like it did before.
Comment by Kimmo (Dehir) - Sunday, 27 June 2010, 14:32 GMT
any idea anyone tried to open new bug for this one. Not sure about my "power button" bug nature. Need to check is it really related to kernel version.
Comment by Mathias Andersson (Wraul) - Sunday, 27 June 2010, 15:02 GMT
Michael: Unfortunately I have not solved this yet. I have since upgraded to 2.6.34 with the same result.
I'm rather confident that this isn't really a bug but simply a change in how wake using a remote is handled. I guess it's actually an improvement, but the remote drivers need to handle this new functionality before waking from suspend using the remote will work again. In my case as far as I understand that would be lirc_mceusb.
Maybe there should be a bug report to lirc?
Like you say it might be possible to manually write something to sysfs to temporarily fix this. I'm not sure if, how, what and where though.
Comment by Gerardo Exequiel Pozzi (djgera) - Monday, 30 August 2010, 06:09 GMT
status with 2.6.35.4? Upstream know about this issue?
Comment by Michael Zanetti (mzanetti) - Sunday, 05 September 2010, 11:45 GMT
update: The code that introduced this issue has been reverted upstream. Due to another change in the USB system of the kernel this still doesn't work out of the box any more. However, you can re-activate the functionality by doing this _in addition_ to the procedure in the initial report:

- find out your receivers USB-ID with lsusb
- echo enabled > /sys/bus/usb/devices/bus-id.device-id/power/wakeup

You should now be able to wake up the PC using the remote again.

So I guess this bug can be closed now.
Thanks

Loading...