Changes in sleep mode, on x86 PC

DISCUSSION Pavel Machek 4 participants 9 messages Mar 28, 2016 – Mar 30, 2016 ACPI

Share & tools

Pavel Machek

author

2016-03-28 21:20 UTC #0 lore raw

Hi!

Few releases ago, I could wake up PC from S3 sleep by hitting any key. That ceased to work some time before, keyboard would just light a NUM lock LED when I hit a key (4.5). Now PC seems to be sleeping (in S3) with NUM lock LED on (4.6-rc0).

Any idea what is going on there? Does it happen for you, too? What is the expected behaviour?

Debian 8.3, with MATE desktop, I just hit the "moon" key to make it sleep. Keyboard is on USB.

Thanks,
Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Rafael J. Wysocki

2016-03-29 13:04 UTC #1 lore raw

Quoted 7 lines · Pavel Machek

Hi!
Few releases ago, I could wake up PC from S3 sleep by hitting any key. That ceased to work some time before, keyboard would just light a NUM lock LED when I hit a key (4.5). Now PC seems to be sleeping (in S3) with NUM lock LED on (4.6-rc0).

Quoted 5 lines

Any idea what is going on there? Does it happen for you, too? What is the expected behaviour?
Debian 8.3, with MATE desktop, I just hit the "moon" key to make it sleep. Keyboard is on USB.

That's rather important.

Clearly, something in the USB HID land has changed lately.

The expected behavior depends on whether or not the keyboard itself and the USB controller are both enabled to wake up. If they are, I'd expect any key press to generate a wakeup event.

Thanks,
Rafael

Oliver Neukum

2016-03-29 14:00 UTC #2 lore raw

Quoted 11 lines · Rafael J. Wysocki

Quoted 10 lines · Pavel Machek
Hi!
Few releases ago, I could wake up PC from S3 sleep by hitting any key. That ceased to work some time before, keyboard would just light a NUM lock LED when I hit a key (4.5). Now PC seems to be sleeping (in S3) with NUM lock LED on (4.6-rc0).
Any idea what is going on there? Does it happen for you, too? What is the expected behaviour?

Quoted 6 lines

Quoted 2 lines
Debian 8.3, with MATE desktop, I just hit the "moon" key to make it sleep. Keyboard is on USB.
That's rather important.
Clearly, something in the USB HID land has changed lately.

Not necessarily. ACPI may also be the root cause.

Quoted 3 lines

The expected behavior depends on whether or not the keyboard itself and the USB controller are both enabled to wake up. If they are, I'd expect any key press to generate a wakeup event.

What does /proc/acpi/wakeup say?

Regards
Oliver

Pavel Machek

author

2016-03-29 14:15 UTC #3 lore raw

Hi!

Quoted 8 lines · Oliver Neukum

Quoted 7 lines · Rafael J. Wysocki
Quoted 6 lines · Pavel Machek
Hi!
Few releases ago, I could wake up PC from S3 sleep by hitting any key. That ceased to work some time before, keyboard would just light a NUM lock LED when I hit a key (4.5). Now PC seems to be sleeping (in S3) with NUM lock LED on (4.6-rc0).

Ok, that "sleeping with numlock LED on" is not reproducible.

Quoted 11 lines

Quoted 9 lines
Quoted 5 lines
Any idea what is going on there? Does it happen for you, too? What is the expected behaviour?
Debian 8.3, with MATE desktop, I just hit the "moon" key to make it sleep. Keyboard is on USB.
That's rather important.
Clearly, something in the USB HID land has changed lately.
Not necessarily. ACPI may also be the root cause.

Ok, that breakage may be year-or-so old.

Quoted 5 lines

Quoted 3 lines
The expected behavior depends on whether or not the keyboard itself and the USB controller are both enabled to wake up. If they are, I'd expect any key press to generate a wakeup event.
What does /proc/acpi/wakeup say?

Device S-state Status Sysfs node

P0P1	  S3	*disabled  pci:0000:00:01.0
P0P2	  S4	*disabled  pci:0000:00:1e.0
PS2K	  S3	*disabled
PS2M	  S3	*disabled
UAR1	  S3	*disabled  pnp:00:03
USB0	  S3	*enabled   pci:0000:00:1d.0
USB1	  S3	*enabled   pci:0000:00:1d.1
USB2	  S3	*enabled   pci:0000:00:1d.2
USB3	  S3	*enabled   pci:0000:00:1d.3
EUSB	  S4	*enabled   pci:0000:00:1d.7
P0P9	  S4	*disabled  pci:0000:00:1c.0
P0PA	  S4	*disabled  pci:0000:00:1c.1
P0PB	  S4	*disabled
P0PC	  S4	*disabled
P0PD	  S4	*disabled
P0PE	  S4	*disabled
PWRB	  S3	*enabled   platform:PNP0C0C:00

Directly-connected USB keyboard. Numlock goes on when I hit a key, but it stays sleeping.

Thanks,
Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Pavel Machek

author

2016-03-29 14:24 UTC #4 lore raw

In reply to Rafael J. Wysocki

Quoted 14 lines · Rafael J. Wysocki

Quoted 7 lines · Pavel Machek
Hi!
Few releases ago, I could wake up PC from S3 sleep by hitting any key. That ceased to work some time before, keyboard would just light a NUM lock LED when I hit a key (4.5). Now PC seems to be sleeping (in S3) with NUM lock LED on (4.6-rc0).
Quoted 5 lines
Any idea what is going on there? Does it happen for you, too? What is the expected behaviour?
Debian 8.3, with MATE desktop, I just hit the "moon" key to make it sleep. Keyboard is on USB.

Quoted 7 lines

That's rather important.
Clearly, something in the USB HID land has changed lately.
The expected behavior depends on whether or not the keyboard itself and the USB controller are both enabled to wake up. If they are, I'd expect any key press to generate a wakeup event.

Is there anything in /sys I should check?

pavel@amd:/sys/class/input/input43$ ls
capabilities  id			 input43::scrolllock  phys
 subsystem
 device	      input43::capslock  modalias	      power
 uevent
 event8	      input43::numlock	 name		      properties  uniq
 pavel@amd:/sys/class/input/input43$ cat power/
 async                   runtime_active_kids     runtime_status
 autosuspend_delay_ms    runtime_active_time
 runtime_suspended_time
 control                 runtime_enabled         runtime_usage
 pavel@amd:/sys/class/input/input43$ cat power/

Ok, this is slightly weird, but it seems to be just multimedia keys having separate device:

pavel@amd:/sys/class/input$ grep . input4*/name
input43/name:Chicony USB Keyboard
input44/name:Chicony USB Keyboard

pavel@amd:/sys/class/input$ ls input43/
capabilities  id	        input43::scrolllock  phys
subsystem
device	      input43::capslock  modalias	      power
uevent
event8	      input43::numlock	 name		      properties  uniq
pavel@amd:/sys/class/input$ ls input44
capabilities  event9  modalias phys   properties  uevent
device	            id      name      power  subsystem   uniq

Thanks,
Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Rafael J. Wysocki

2016-03-29 21:44 UTC #5 lore raw

Quoted 18 lines · Pavel Machek

Quoted 16 lines · Rafael J. Wysocki
Quoted 7 lines · Pavel Machek
Hi!
Few releases ago, I could wake up PC from S3 sleep by hitting any key. That ceased to work some time before, keyboard would just light a NUM lock LED when I hit a key (4.5). Now PC seems to be sleeping (in S3) with NUM lock LED on (4.6-rc0).
Quoted 5 lines
Any idea what is going on there? Does it happen for you, too? What is the expected behaviour?
Debian 8.3, with MATE desktop, I just hit the "moon" key to make it sleep. Keyboard is on USB.
That's rather important.

Quoted 7 lines

Quoted 5 lines
Clearly, something in the USB HID land has changed lately.
The expected behavior depends on whether or not the keyboard itself and the USB controller are both enabled to wake up. If they are, I'd expect any key press to generate a wakeup event.
Is there anything in /sys I should check?

Generally, power/wakeup files under the involved devices (ie. if they are present and what's in them if so).

Thanks,
Rafael

Pavel Machek

author

2016-03-29 21:56 UTC #6 lore raw

Quoted 21 lines · Rafael J. Wysocki

Quoted 20 lines · Pavel Machek
Quoted 18 lines · Rafael J. Wysocki
Quoted 7 lines · Pavel Machek
Hi!
Few releases ago, I could wake up PC from S3 sleep by hitting any key. That ceased to work some time before, keyboard would just light a NUM lock LED when I hit a key (4.5). Now PC seems to be sleeping (in S3) with NUM lock LED on (4.6-rc0).
Quoted 5 lines
Any idea what is going on there? Does it happen for you, too? What is the expected behaviour?
Debian 8.3, with MATE desktop, I just hit the "moon" key to make it sleep. Keyboard is on USB.
That's rather important.
Clearly, something in the USB HID land has changed lately.

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
The expected behavior depends on whether or not the keyboard itself and the USB controller are both enabled to wake up. If they are, I'd expect any key press to generate a wakeup event.
Is there anything in /sys I should check?
Generally, power/wakeup files under the involved devices (ie. if they are present and what's in them if so).

/sys/class/input43 and 44 (corresponding to USB keyboard) has no such files.

pavel@amd:/sys/devices/pci0000:00$ lsusb
Bus 001 Device 008: ID 046d:c05a Logitech, Inc. M90/M100 Optical Mouse
Bus 001 Device 064: ID 04f2:0111 Chicony Electronics Co., Ltd KU-9908
Keyboard
Bus 001 Device 005: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 001 Device 006: ID 0557:2008 ATEN International Co., Ltd UC-232A
Serial Port [pl2303]
Bus 001 Device 004: ID 058f:6254 Alcor Micro Corp. USB Hub
Bus 001 Device 071: ID 1004:618e LG Electronics, Inc. Ally/Optimus
One/Vortex (debug mode)
Bus 001 Device 002: ID 058f:6362 Alcor Micro Corp. Flash Card
Reader/Writer
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

There are rather a lot of wakeup files here:

pavel@amd:/sys/devices/pci0000:00$ find . -name "wakeup"
./0000:00:01.0/power/wakeup
./0000:00:1b.0/power/wakeup
./0000:00:1c.0/power/wakeup
./0000:00:1c.1/power/wakeup
./0000:00:1c.1/0000:03:00.0/power/wakeup
./0000:00:1d.0/usb2/power/wakeup
./0000:00:1d.0/power/wakeup
./0000:00:1d.1/usb3/power/wakeup
./0000:00:1d.1/power/wakeup
./0000:00:1d.2/usb4/power/wakeup
./0000:00:1d.2/power/wakeup
./0000:00:1d.3/usb5/power/wakeup
./0000:00:1d.3/power/wakeup
./0000:00:1d.7/usb1/1-5/power/wakeup
./0000:00:1d.7/usb1/1-6/1-6.2/power/wakeup
./0000:00:1d.7/usb1/1-6/power/wakeup
./0000:00:1d.7/usb1/1-7/1-7.1/power/wakeup
./0000:00:1d.7/usb1/1-7/1-7.2/power/wakeup
./0000:00:1d.7/usb1/1-7/power/wakeup
./0000:00:1d.7/usb1/power/wakeup
./0000:00:1d.7/power/wakeup
./0000:00:1e.0/power/wakeup
./0000:00:1f.2/power/wakeup
pavel@amd:/sys/devices/pci0000:00$

root@amd:/sys/devices/pci0000:00# for a in `find . -name "wakeup"`; do
echo $a `cat $a`; done
./0000:00:01.0/power/wakeup disabled
./0000:00:1b.0/power/wakeup disabled
./0000:00:1c.0/power/wakeup disabled
./0000:00:1c.1/power/wakeup disabled
./0000:00:1c.1/0000:03:00.0/power/wakeup enabled
./0000:00:1d.0/usb2/power/wakeup disabled
./0000:00:1d.0/power/wakeup enabled
./0000:00:1d.1/usb3/power/wakeup disabled
./0000:00:1d.1/power/wakeup enabled
./0000:00:1d.2/usb4/power/wakeup disabled
./0000:00:1d.2/power/wakeup enabled
./0000:00:1d.3/usb5/power/wakeup disabled
./0000:00:1d.3/power/wakeup enabled
./0000:00:1d.7/usb1/1-5/power/wakeup disabled
./0000:00:1d.7/usb1/1-6/1-6.2/power/wakeup disabled
./0000:00:1d.7/usb1/1-6/power/wakeup disabled
./0000:00:1d.7/usb1/1-7/1-7.1/power/wakeup enabled
./0000:00:1d.7/usb1/1-7/1-7.2/power/wakeup disabled
./0000:00:1d.7/usb1/1-7/power/wakeup disabled
./0000:00:1d.7/usb1/power/wakeup disabled
./0000:00:1d.7/power/wakeup enabled
./0000:00:1e.0/power/wakeup disabled
./0000:00:1f.2/power/wakeup disabled
root@amd:/sys/devices/pci0000:00#

And the defaults are interesting, to say. But with:

for a in find . -name "wakeup"; do echo enabled > $a; done

It seems to wake up when I hit a key. So next question is... what should be the default behaviour?
Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Rafael J. Wysocki

2016-03-29 22:02 UTC #7 lore raw

Quoted 108 lines · Pavel Machek

Quoted 21 lines · Rafael J. Wysocki

Quoted 20 lines · Pavel Machek
Quoted 18 lines · Rafael J. Wysocki
Quoted 7 lines · Pavel Machek
Hi!
Few releases ago, I could wake up PC from S3 sleep by hitting any key. That ceased to work some time before, keyboard would just light a NUM lock LED when I hit a key (4.5). Now PC seems to be sleeping (in S3) with NUM lock LED on (4.6-rc0).
Quoted 5 lines
Any idea what is going on there? Does it happen for you, too? What is the expected behaviour?
Debian 8.3, with MATE desktop, I just hit the "moon" key to make it sleep. Keyboard is on USB.
That's rather important.
Clearly, something in the USB HID land has changed lately.

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
The expected behavior depends on whether or not the keyboard itself and the USB controller are both enabled to wake up. If they are, I'd expect any key press to generate a wakeup event.
Is there anything in /sys I should check?
Generally, power/wakeup files under the involved devices (ie. if they are present and what's in them if so).

/sys/class/input43 and 44 (corresponding to USB keyboard) has no such files.

pavel@amd:/sys/devices/pci0000:00$ lsusb
Bus 001 Device 008: ID 046d:c05a Logitech, Inc. M90/M100 Optical Mouse
Bus 001 Device 064: ID 04f2:0111 Chicony Electronics Co., Ltd KU-9908
Keyboard
Bus 001 Device 005: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 001 Device 006: ID 0557:2008 ATEN International Co., Ltd UC-232A
Serial Port [pl2303]
Bus 001 Device 004: ID 058f:6254 Alcor Micro Corp. USB Hub
Bus 001 Device 071: ID 1004:618e LG Electronics, Inc. Ally/Optimus
One/Vortex (debug mode)
Bus 001 Device 002: ID 058f:6362 Alcor Micro Corp. Flash Card
Reader/Writer
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

There are rather a lot of wakeup files here:

pavel@amd:/sys/devices/pci0000:00$ find . -name "wakeup"
./0000:00:01.0/power/wakeup
./0000:00:1b.0/power/wakeup
./0000:00:1c.0/power/wakeup
./0000:00:1c.1/power/wakeup
./0000:00:1c.1/0000:03:00.0/power/wakeup
./0000:00:1d.0/usb2/power/wakeup
./0000:00:1d.0/power/wakeup
./0000:00:1d.1/usb3/power/wakeup
./0000:00:1d.1/power/wakeup
./0000:00:1d.2/usb4/power/wakeup
./0000:00:1d.2/power/wakeup
./0000:00:1d.3/usb5/power/wakeup
./0000:00:1d.3/power/wakeup
./0000:00:1d.7/usb1/1-5/power/wakeup
./0000:00:1d.7/usb1/1-6/1-6.2/power/wakeup
./0000:00:1d.7/usb1/1-6/power/wakeup
./0000:00:1d.7/usb1/1-7/1-7.1/power/wakeup
./0000:00:1d.7/usb1/1-7/1-7.2/power/wakeup
./0000:00:1d.7/usb1/1-7/power/wakeup
./0000:00:1d.7/usb1/power/wakeup
./0000:00:1d.7/power/wakeup
./0000:00:1e.0/power/wakeup
./0000:00:1f.2/power/wakeup
pavel@amd:/sys/devices/pci0000:00$

root@amd:/sys/devices/pci0000:00# for a in `find . -name "wakeup"`; do
echo $a `cat $a`; done
./0000:00:01.0/power/wakeup disabled
./0000:00:1b.0/power/wakeup disabled
./0000:00:1c.0/power/wakeup disabled
./0000:00:1c.1/power/wakeup disabled
./0000:00:1c.1/0000:03:00.0/power/wakeup enabled
./0000:00:1d.0/usb2/power/wakeup disabled
./0000:00:1d.0/power/wakeup enabled
./0000:00:1d.1/usb3/power/wakeup disabled
./0000:00:1d.1/power/wakeup enabled
./0000:00:1d.2/usb4/power/wakeup disabled
./0000:00:1d.2/power/wakeup enabled
./0000:00:1d.3/usb5/power/wakeup disabled
./0000:00:1d.3/power/wakeup enabled
./0000:00:1d.7/usb1/1-5/power/wakeup disabled
./0000:00:1d.7/usb1/1-6/1-6.2/power/wakeup disabled
./0000:00:1d.7/usb1/1-6/power/wakeup disabled
./0000:00:1d.7/usb1/1-7/1-7.1/power/wakeup enabled
./0000:00:1d.7/usb1/1-7/1-7.2/power/wakeup disabled
./0000:00:1d.7/usb1/1-7/power/wakeup disabled
./0000:00:1d.7/usb1/power/wakeup disabled
./0000:00:1d.7/power/wakeup enabled
./0000:00:1e.0/power/wakeup disabled
./0000:00:1f.2/power/wakeup disabled
root@amd:/sys/devices/pci0000:00#

Quoted 6 lines

And the defaults are interesting, to say. But with:
for a in find . -name "wakeup"; do echo enabled > $a; done
It seems to wake up when I hit a key. So next question is... what should be the default behaviour?

That's rather hard to answer.

Ideally, "enabled", but then some of those things generate spurious wakeup events and the owners of these prefer "disabled".

Thanks,
Rafael

Alan Stern

2016-03-30 14:48 UTC #8 lore raw

Quoted 113 lines · Rafael J. Wysocki

Quoted 112 lines · Pavel Machek
Quoted 21 lines · Rafael J. Wysocki
Quoted 20 lines · Pavel Machek
Quoted 18 lines · Rafael J. Wysocki
Quoted 7 lines · Pavel Machek
Hi!
Few releases ago, I could wake up PC from S3 sleep by hitting any key. That ceased to work some time before, keyboard would just light a NUM lock LED when I hit a key (4.5). Now PC seems to be sleeping (in S3) with NUM lock LED on (4.6-rc0).
Quoted 5 lines
Any idea what is going on there? Does it happen for you, too? What is the expected behaviour?
Debian 8.3, with MATE desktop, I just hit the "moon" key to make it sleep. Keyboard is on USB.
That's rather important.
Clearly, something in the USB HID land has changed lately.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
The expected behavior depends on whether or not the keyboard itself and the USB controller are both enabled to wake up. If they are, I'd expect any key press to generate a wakeup event.
Is there anything in /sys I should check?
Generally, power/wakeup files under the involved devices (ie. if they are present and what's in them if so).
/sys/class/input43 and 44 (corresponding to USB keyboard) has no such files.
pavel@amd:/sys/devices/pci0000:00$ lsusb
Bus 001 Device 008: ID 046d:c05a Logitech, Inc. M90/M100 Optical Mouse
Bus 001 Device 064: ID 04f2:0111 Chicony Electronics Co., Ltd KU-9908
Keyboard
Bus 001 Device 005: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 001 Device 006: ID 0557:2008 ATEN International Co., Ltd UC-232A
Serial Port [pl2303]
Bus 001 Device 004: ID 058f:6254 Alcor Micro Corp. USB Hub
Bus 001 Device 071: ID 1004:618e LG Electronics, Inc. Ally/Optimus
One/Vortex (debug mode)
Bus 001 Device 002: ID 058f:6362 Alcor Micro Corp. Flash Card
Reader/Writer
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
There are rather a lot of wakeup files here:
pavel@amd:/sys/devices/pci0000:00$ find . -name "wakeup"
./0000:00:01.0/power/wakeup
./0000:00:1b.0/power/wakeup
./0000:00:1c.0/power/wakeup
./0000:00:1c.1/power/wakeup
./0000:00:1c.1/0000:03:00.0/power/wakeup
./0000:00:1d.0/usb2/power/wakeup
./0000:00:1d.0/power/wakeup
./0000:00:1d.1/usb3/power/wakeup
./0000:00:1d.1/power/wakeup
./0000:00:1d.2/usb4/power/wakeup
./0000:00:1d.2/power/wakeup
./0000:00:1d.3/usb5/power/wakeup
./0000:00:1d.3/power/wakeup
./0000:00:1d.7/usb1/1-5/power/wakeup
./0000:00:1d.7/usb1/1-6/1-6.2/power/wakeup
./0000:00:1d.7/usb1/1-6/power/wakeup
./0000:00:1d.7/usb1/1-7/1-7.1/power/wakeup
./0000:00:1d.7/usb1/1-7/1-7.2/power/wakeup
./0000:00:1d.7/usb1/1-7/power/wakeup
./0000:00:1d.7/usb1/power/wakeup
./0000:00:1d.7/power/wakeup
./0000:00:1e.0/power/wakeup
./0000:00:1f.2/power/wakeup
pavel@amd:/sys/devices/pci0000:00$
root@amd:/sys/devices/pci0000:00# for a in `find . -name "wakeup"`; do
echo $a `cat $a`; done
./0000:00:01.0/power/wakeup disabled
./0000:00:1b.0/power/wakeup disabled
./0000:00:1c.0/power/wakeup disabled
./0000:00:1c.1/power/wakeup disabled
./0000:00:1c.1/0000:03:00.0/power/wakeup enabled
./0000:00:1d.0/usb2/power/wakeup disabled
./0000:00:1d.0/power/wakeup enabled
./0000:00:1d.1/usb3/power/wakeup disabled
./0000:00:1d.1/power/wakeup enabled
./0000:00:1d.2/usb4/power/wakeup disabled
./0000:00:1d.2/power/wakeup enabled
./0000:00:1d.3/usb5/power/wakeup disabled
./0000:00:1d.3/power/wakeup enabled
./0000:00:1d.7/usb1/1-5/power/wakeup disabled
./0000:00:1d.7/usb1/1-6/1-6.2/power/wakeup disabled
./0000:00:1d.7/usb1/1-6/power/wakeup disabled
./0000:00:1d.7/usb1/1-7/1-7.1/power/wakeup enabled
./0000:00:1d.7/usb1/1-7/1-7.2/power/wakeup disabled
./0000:00:1d.7/usb1/1-7/power/wakeup disabled
./0000:00:1d.7/usb1/power/wakeup disabled
./0000:00:1d.7/power/wakeup enabled
./0000:00:1e.0/power/wakeup disabled
./0000:00:1f.2/power/wakeup disabled
root@amd:/sys/devices/pci0000:00#
And the defaults are interesting, to say. But with:
for a in find . -name "wakeup"; do echo enabled > $a; done

Quoted 7 lines

Quoted 2 lines
It seems to wake up when I hit a key. So next question is... what should be the default behaviour?
That's rather hard to answer.
Ideally, "enabled", but then some of those things generate spurious wakeup events and the owners of these prefer "disabled".

Unforunately, lsusb does not print out the port number information needed to match its output against the sysfs files. (Not to mention that the lsusb output shows 7 non-root-hub devices on bus 1 but the sysfs listing shows only 6!) I'd guess that the keyboard is 0000:00:1d.7/usb1/1-7/1-7.1/ because it's the only entry with wakeup enabled. What do 0000:00:1d.7/usb1/1-7/1-7.1/{product,vendor} contain?

If so, the missing ingredient may be that you need to enable 0000:00:1d.7/usb1/1-7/power/wakeup, because that's the keyboard's parent hub. The USB spec says that hubs are required always to relay wakeup requests from their children to their parents, but not all hubs do this.

The disadvantage of enabling wakeup on a hub is that it will then generate a wakeup request whenever a device is plugged in or unplugged. That's why hubs default to disabled.

On the other hand, if this used to work okay then it's unlikely that the hub is at fault. It's more likely that something has changed in PCI or ACPI, so that the wakeup signal from 0000:00:1d.7 isn't sending the computer back to S0. But that doesn't explain why writing "enabled" to all the power/wakeup files would make things start working again.

Alan Stern