View previous topic :: View next topic |
Author |
Message |
avx Advocate
Joined: 21 Jun 2004 Posts: 2152
|
Posted: Thu May 17, 2012 1:11 pm Post subject: [workaround] wake up via keyboard/mouse no longer works |
|
|
// thanks to @danomac, the feature itself is working for me again - check his link further down, but the real problem isn't solved, yet
After upgrading my kernel from 3.1.1 to 3.3.5 (both times gentoo-sources), I can no longer wake up this machine by pressing a key on the keyboard or clicking/moving the mouse, which used to work flawless before. Shortly pressing a key lights up the numlock-key, indicating it's under power, but nothing more happens - wake up via powerbutton works.
Here's a diff -u (~800 lines) between the two .config's and this is the output of `acpitool -w`
Code: | Device S-state Status Sysfs node
---------------------------------------
1. NPE2 S4 *disabled
2. NPE4 S4 *disabled
3. NPE5 S4 *disabled
4. NPE6 S4 *disabled
5. NPE8 S4 *disabled
6. NPE9 S4 *disabled
7. NPEA S4 *disabled
8. P0P1 S4 *disabled pci:0000:00:1e.0
9. USB0 S4 *enabled pci:0000:00:1d.0
10. USB1 S4 *enabled pci:0000:00:1d.1
11. USB2 S4 *enabled pci:0000:00:1d.2
12. USB5 S4 *disabled
13. EUSB S4 *enabled pci:0000:00:1d.7
14. USB3 S4 *enabled pci:0000:00:1a.0
15. USB4 S4 *enabled pci:0000:00:1a.1
16. USB6 S4 *enabled pci:0000:00:1a.2
17. USBE S4 *enabled pci:0000:00:1a.7
18. P0P4 S4 *enabled pci:0000:00:1c.0
19. P0P5 S4 *disabled
20. P0P6 S4 *enabled pci:0000:00:1c.2
21. P0P7 S4 *disabled
22. P0P8 S4 *disabled
23. P0P9 S4 *disabled
24. NPE1 S4 *enabled pci:0000:00:01.0
25. NPE3 S4 *enabled pci:0000:00:03.0
26. NPE7 S4 *enabled pci:0000:00:07.0
27. GBE S4 *disabled |
Devices in question, according to `lsusb`
Code: | Bus 003 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 008 Device 002: ID 046a:0023 Cherry GmbH CyMotion Master Linux Keyboard |
_________________ ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.
Last edited by avx on Mon Aug 20, 2012 2:40 pm; edited 2 times in total |
|
Back to top |
|
|
redmaniac n00b
Joined: 21 Sep 2011 Posts: 39
|
Posted: Sun Jun 24, 2012 8:46 am Post subject: |
|
|
same here, I upgraded from 3.2.12 to 3.3.8. Just as in avx's case, my kernels are both gentoo-sources.
If anybody has any insights, I'd also be happy to hear about them. |
|
Back to top |
|
|
avx Advocate
Joined: 21 Jun 2004 Posts: 2152
|
Posted: Thu Jul 12, 2012 4:38 pm Post subject: |
|
|
Bumping this, currently at 3.4.2, same problem. _________________ ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>. |
|
Back to top |
|
|
avx Advocate
Joined: 21 Jun 2004 Posts: 2152
|
Posted: Wed Jul 25, 2012 1:29 pm Post subject: |
|
|
Now on 3.5.0, still doesn't work and I'm getting pissed. _________________ ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>. |
|
Back to top |
|
|
Thistled Guru
Joined: 06 Jan 2011 Posts: 572 Location: Scotland
|
Posted: Thu Jul 26, 2012 12:14 am Post subject: |
|
|
Not that this will help, but I have not been able to wake up via a USB attachment for over a year.
I can no longer hibernate either. Not me, the PC.
I can however suspend. Sure no mouse or keyboard hit or click will awaken, but as soon as I hit the power button, I have a resumed desktop within 5 seconds.
So why not just hit the power button? _________________ Whatever you do, do it properly! |
|
Back to top |
|
|
avx Advocate
Joined: 21 Jun 2004 Posts: 2152
|
Posted: Thu Jul 26, 2012 6:05 am Post subject: |
|
|
Thistled wrote: | So why not just hit the power button? | Because it's door->desk, reach over it, press key, walk around desk, sit, machine is one vs. walk a few meters more, press button, return - the machine is placed rather far away, which normally doesn't matter.
I googled around a little and so far found no other notices on other distributions where people are newly having this problem, only people who never had it working in the first place.
If I'd were better in kernel stuff or had a clue, where the problem might be located, I'd try to fix it, but I'm not really willing to `git bisect` over dozens of kernel changes. _________________ ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>. |
|
Back to top |
|
|
danomac l33t
Joined: 06 Nov 2004 Posts: 881 Location: Vancouver, BC
|
Posted: Wed Aug 15, 2012 1:11 am Post subject: |
|
|
I just compiled 3.3.8 and discovered this exact problem. Keyboard lights up but nobody's home!
Code: |
# dmesg
input: G15 Keyboard G15 Keyboard as /devices/pci0000:00/0000:00:1a.1/usb4/4-2/4-2.4/4-2.4:1.0/input/input6
generic-usb 0003:046D:C222.0005: input,hiddev0,hidraw4: USB HID v1.11 Keypad [G15 Keyboard G15 Keyboard] on usb-0000:00:1a.1-2.4/input0
## cat /sys/devices/pci0000\:00/0000\:00\:1a.1/usb4/power/wakeup
enabled
|
What the ??
Edit:
Even more curious:
Code: |
# acpitool -e
Kernel version : 3.3.8-gentoo - ACPI version : 20120111
-----------------------------------------------------------
Battery status : <not available>
AC adapter : <info not available or off-line>
Fan : <not available>
CPU type : Intel(R) Core(TM)2 Extreme CPU X9650 @ 3.00GHz
Min/Max frequency : 1998/2997 MHz
Current frequency : 2997 MHz
Frequency governor : performance
Freq. scaling driver : acpi-cpufreq
Cache size : 2997.000 KB
Bogomips : 5985.39
Bogomips : 5985.39
Bogomips : 5985.39
Bogomips : 5985.39
Function Show_CPU_Info : could not read directory /proc/acpi/processor/
Make sure your kernel has ACPI processor support enabled.
Thermal info : <not available>
Device S-state Status Sysfs node
---------------------------------------
1. P0P1 S3 *disabled pci:0000:00:01.0
2. UAR1 S3 *disabled pnp:00:03
3. P0P2 S4 *disabled pci:0000:00:1e.0
4. USB0 S3 *enabled pci:0000:00:1d.0
5. USB1 S3 *enabled pci:0000:00:1d.1
6. USB2 S3 *enabled pci:0000:00:1d.2
7. USB5 S3 *disabled
8. USB6 S3 *enabled pci:0000:00:1a.2
9. EUSB S3 *enabled pci:0000:00:1d.7
10. USB3 S3 *enabled pci:0000:00:1a.0
11. USB4 S3 *disabled pci:0000:00:1a.1 <-- huh?
12. USBE S3 *enabled pci:0000:00:1a.7
13. PEX0 S4 *disabled pci:0000:00:1c.0
14. PEX1 S4 *disabled pci:0000:00:1c.1
15. PEX2 S4 *disabled pci:0000:00:1c.2
16. PEX3 S4 *disabled pci:0000:00:1c.3
17. PEX4 S4 *disabled pci:0000:00:1c.4
18. PEX5 S4 *disabled pci:0000:00:1c.5
19. SLPB S4 *enabled
20. PWRB S3 *enabled
|
Enabled in one place, disabled the next???
Edit2:
Even more strange:
Code: |
# dmesg | grep Keyboard
usb 4-2.4: Product: G15 Keyboard
usb 4-2.4: Manufacturer: G15 Keyboard
input: G15 Keyboard G15 Keyboard as /devices/pci0000:00/0000:00:1a.1/usb4/4-2/4-2.4/4-2.4:1.0/input/input6
generic-usb 0003:046D:C222.0005: input,hiddev0,hidraw4: USB HID v1.11 Keypad [G15 Keyboard G15 Keyboard] on usb-0000:00:1a.1-2.4/input0
# find /sys/devices/pci0000\:00/0000\:00\:1a.1/usb4 -iname wakeup
/sys/devices/pci0000:00/0000:00:1a.1/usb4/power/wakeup
/sys/devices/pci0000:00/0000:00:1a.1/usb4/4-1/power/wakeup
/sys/devices/pci0000:00/0000:00:1a.1/usb4/4-2/4-2.1/power/wakeup
# find /sys/devices/pci0000\:00/0000\:00\:1a.1/usb4 -iname wakeup -exec cat {} \;
disabled
disabled
enabled
|
Yet:
Code: |
# cat /proc/acpi/wakeup | grep USB4
USB4 S3 *disabled pci:0000:00:1a.1
|
So the device is enabled but the bus isn't? How bizarre. I didn't have to do anything before to get it to work.
Tried sleeping, no go. But
Code: |
# echo 'USB4' > /proc/acpi/wakeup
# cat /proc/acpi/wakeup | grep USB4
USB4 S3 *enabled pci:0000:00:1a.1
|
Now it works again! But even stranger still:
Code: |
# find /sys/devices/pci0000\:00/0000\:00\:1a.1/usb4 -iname wakeup
/sys/devices/pci0000:00/0000:00:1a.1/usb4/power/wakeup
/sys/devices/pci0000:00/0000:00:1a.1/usb4/4-1/power/wakeup
/sys/devices/pci0000:00/0000:00:1a.1/usb4/4-2/4-2.1/power/wakeup
# find /sys/devices/pci0000\:00/0000\:00\:1a.1/usb4 -iname wakeup -exec cat {} \;
disabled
disabled
enabled
|
What the hell? It seems there's a disconnect! udev was one of the updates, maybe a ruleset changed?
Edit3:
Ah-HA! Apparently I did have to do something before! I had a file in /etc/local.d/ called 'enableusbwake.start' with 'echo "USB4" > /proc/acpi/wakeup' in it. Apparently it's been so long I forgot.
It appears udev is now setting this automatically. So I removed the file in /etc/local.d/ and rebooted and alas, it works again. udev was setting it correctly and my script was disabling it!
Edit4:
Nope not quite working. According to this:
Code: |
# find /sys/devices/pci0000\:00/0000\:00\:1a.1/usb4 -iname wakeup
/sys/devices/pci0000:00/0000:00:1a.1/usb4/power/wakeup
/sys/devices/pci0000:00/0000:00:1a.1/usb4/4-1/power/wakeup
/sys/devices/pci0000:00/0000:00:1a.1/usb4/4-2/4-2.1/power/wakeup
# find /sys/devices/pci0000\:00/0000\:00\:1a.1/usb4 -iname wakeup -exec cat {} \;
disabled
disabled
enabled
|
The keyboard was enabled but the USB hub itself was not (the first line/response.) /proc/acpi/wakeup indicates it IS enabled, but it clearly is not.
I created /etc/local.d/enableusbwakeup.start with:
Code: |
#!/bin/sh
echo 'enabled' > /sys/devices/pci0000\:00/0000\:00\:1a.1/usb4/power/wakeup
|
and rebooted. Now I have:
Code: |
# cat /proc/acpi/wakeup |grep USB4
USB4 S3 *enabled pci:0000:00:1a.1
# find /sys/devices/pci0000\:00/0000\:00\:1a.1/usb4 -iname wakeup
/sys/devices/pci0000:00/0000:00:1a.1/usb4/power/wakeup
/sys/devices/pci0000:00/0000:00:1a.1/usb4/4-1/power/wakeup
/sys/devices/pci0000:00/0000:00:1a.1/usb4/4-2/4-2.1/power/wakeup
# find /sys/devices/pci0000\:00/0000\:00\:1a.1/usb4 -iname wakeup -exec cat {} \;
enabled
disabled
enabled
|
And I can put it to sleep and wake it up with the keyboard like I usually can. Tried several times, works a-ok. So basically using /proc/acpi/wakeup is useless now, or it's not in sync or something...
If you are having this problem you'll have to identify your keyboard and then create a file in /etc/local.d/ like I have (your USB IDs will obviously be different.) Sigh... |
|
Back to top |
|
|
avx Advocate
Joined: 21 Jun 2004 Posts: 2152
|
Posted: Wed Aug 15, 2012 12:48 pm Post subject: |
|
|
Wow, long text, I'll read and try this later, thanks (just a reminder post^^). _________________ ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>. |
|
Back to top |
|
|
danomac l33t
Joined: 06 Nov 2004 Posts: 881 Location: Vancouver, BC
|
Posted: Wed Aug 15, 2012 4:08 pm Post subject: |
|
|
Yeah, sorry about that. I was going and documenting step-by-step what I was trying. It might help others troubleshoot this annoying problem though. It seems that /proc/acpi/wakeup now is not connected to /sys/devices/*... only when I directly toggled the hub in /sys/devices did the stupid thing start working again. I guess there's not much reason to keep the deprecated /proc/acpi in the kernel anymore.
It still works, I woke my computer with the spacebar this morning. |
|
Back to top |
|
|
energyman76b Advocate
Joined: 26 Mar 2003 Posts: 2048 Location: Germany
|
Posted: Wed Aug 15, 2012 11:59 pm Post subject: |
|
|
I am sure there was a similar problem on gentoo-user and it was solved via a kernel config option. You might want to hit the archive. _________________ Study finds stunning lack of racial, gender, and economic diversity among middle-class white males
I identify as a dirty penismensch. |
|
Back to top |
|
|
avx Advocate
Joined: 21 Jun 2004 Posts: 2152
|
Posted: Thu Aug 16, 2012 12:50 am Post subject: |
|
|
Ehm, the archive on http://archives.gentoo.org/gentoo-user/date.xml ends at April 07 2012?!
Anyway, couldn't find something on gmane or via Google, any clue in what timeframe that thread may have been? _________________ ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>. |
|
Back to top |
|
|
danomac l33t
Joined: 06 Nov 2004 Posts: 881 Location: Vancouver, BC
|
Posted: Mon Aug 20, 2012 4:02 am Post subject: |
|
|
I searched too, I couldn't find anything. I used gossamer-threads.com but only found results for up to Nov 2011, but that wasn't the same problem.
I unplugged my computer today to move it, and plugged in the keyboard to the wrong hub so it stopped working again.
The problem is acpitool says stuff is enabled, but under /sys/devices/ it is NOT enabled, and apparently that's the part that matters.
I actually wrote a quick bash script to check and set these things, I posted it in the Tips & Tricks forum. |
|
Back to top |
|
|
avx Advocate
Joined: 21 Jun 2004 Posts: 2152
|
Posted: Mon Aug 20, 2012 2:35 pm Post subject: |
|
|
danomac wrote: | I actually wrote a quick bash script to check and set these things, I posted it in the Tips & Tricks forum. | Testing.
What I'm wondering, if this is somehow device/chipset/... specific, cause my Macbook wakes up just fine without any special treatment, my desktop never did until I played with these things sometime last year.
Edit, Works, thanks.
(marking thread as 'workaround', since obviously there's some kind of misunderstanding or bug here) _________________ ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>. |
|
Back to top |
|
|
danomac l33t
Joined: 06 Nov 2004 Posts: 881 Location: Vancouver, BC
|
Posted: Wed Aug 22, 2012 8:28 pm Post subject: |
|
|
Use of /proc/acpi/* is deprecated, so I doubt it will be fixed... |
|
Back to top |
|
|
avx Advocate
Joined: 21 Jun 2004 Posts: 2152
|
Posted: Wed Aug 22, 2012 9:13 pm Post subject: |
|
|
Doesn't matter, as I said above, I'm running a pretty long time (>1 year) without /proc/acpi and wakeup still worked, up until the point where I did the initial post for this topic. _________________ ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>. |
|
Back to top |
|
|
danomac l33t
Joined: 06 Nov 2004 Posts: 881 Location: Vancouver, BC
|
Posted: Wed Aug 22, 2012 9:50 pm Post subject: |
|
|
Interestingly enough, on my computer /proc/acpi/wakeup still exists, even after removing the deprecated /proc/acpi directories and files from my kernel. I guess acpitool -w is still using /proc/acpi/wakeup but it does not reflect what is actually enabled under /sys/devices.
Does /proc/acpi/wakeup still exist on your install too? |
|
Back to top |
|
|
avx Advocate
Joined: 21 Jun 2004 Posts: 2152
|
Posted: Wed Aug 22, 2012 10:12 pm Post subject: |
|
|
danomac wrote: | Does /proc/acpi/wakeup still exist on your install too? | Yep. _________________ ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>. |
|
Back to top |
|
|
danomac l33t
Joined: 06 Nov 2004 Posts: 881 Location: Vancouver, BC
|
Posted: Tue Sep 18, 2012 8:57 pm Post subject: |
|
|
Hey, the workaround I posted is apparently the fix:
Kernel patch to change USB hub wakeup behavior.
Snippet:
Quote: |
This patch (as1486) implements the kernel's new wakeup policy for USB
host controllers. Since they don't generate wakeup requests on their
but merely forward requests from their root hubs toward the CPU, they
should be enabled for wakeup by default.
Also, to be compliant with both the old and new policies, root hubs
should not be enabled for remote wakeup by default. Userspace must
enable it explicitly if it is desired.
|
So it is fully up to userspace tools (or maybe custom udev rules? Haven't tried that) to re-enable devices that no longer work. |
|
Back to top |
|
|
avx Advocate
Joined: 21 Jun 2004 Posts: 2152
|
Posted: Tue Sep 18, 2012 10:07 pm Post subject: |
|
|
Good to know, thanks.
Though I must say, this pisses me off more then just a little bit. It's a change in default behaviour and there was no notice while building the kernel. Might as well use Fedora/SUSE and let them work for me _________________ ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>. |
|
Back to top |
|
|
danomac l33t
Joined: 06 Nov 2004 Posts: 881 Location: Vancouver, BC
|
Posted: Tue Sep 18, 2012 11:23 pm Post subject: |
|
|
avx wrote: | Good to know, thanks.
Though I must say, this pisses me off more then just a little bit. It's a change in default behaviour and there was no notice while building the kernel. Might as well use Fedora/SUSE and let them work for me |
That's an upstream change. They change stuff all the time without warning people. I still remember my scsi driver failing to build because they changed something in the kernel. |
|
Back to top |
|
|
avx Advocate
Joined: 21 Jun 2004 Posts: 2152
|
Posted: Wed Oct 31, 2012 3:03 pm Post subject: |
|
|
Strange, I didn't run any updates for a while and out of the blue, I've got the same problem again - though your tool showing everything as enabled. Updating the system&kernel to the latest revisions in portage didn't help either _________________ ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>. |
|
Back to top |
|
|
danomac l33t
Joined: 06 Nov 2004 Posts: 881 Location: Vancouver, BC
|
Posted: Wed Oct 31, 2012 3:13 pm Post subject: |
|
|
That is strange. Did you check /proc/acpi/wakeup too?
Mine's been working fine.
(By the way, my sleep started having problems a few months ago. My PSU ruptured a cap and the 5V line was only 4V, not enough for sleep to work properly...) |
|
Back to top |
|
|
avx Advocate
Joined: 21 Jun 2004 Posts: 2152
|
Posted: Wed Oct 31, 2012 3:34 pm Post subject: |
|
|
Aha, for some reason, pretty much everything in /proc/acpi/wakeup was set to disabled. Blindly enabling every device here helped and it's working again. Thanks. _________________ ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>. |
|
Back to top |
|
|
danomac l33t
Joined: 06 Nov 2004 Posts: 881 Location: Vancouver, BC
|
Posted: Wed Oct 31, 2012 3:35 pm Post subject: |
|
|
No problem. |
|
Back to top |
|
|
|