* Changes in sleep mode, on x86 PC @ 2016-03-28 21:20 Pavel Machek 2016-03-29 13:06 ` Rafael J. Wysocki 0 siblings, 1 reply; 9+ messages in thread From: Pavel Machek @ 2016-03-28 21:20 UTC (permalink / raw) To: Rafael J. Wysocki, kernel list, lenb, linux-acpi 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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Changes in sleep mode, on x86 PC 2016-03-28 21:20 Changes in sleep mode, on x86 PC Pavel Machek @ 2016-03-29 13:06 ` Rafael J. Wysocki 2016-03-29 14:00 ` Oliver Neukum 2016-03-29 14:24 ` Pavel Machek 0 siblings, 2 replies; 9+ messages in thread From: Rafael J. Wysocki @ 2016-03-29 13:06 UTC (permalink / raw) To: Pavel Machek; +Cc: kernel list, lenb, linux-acpi, Linux PM list, Jiri Kosina On Monday, March 28, 2016 11:20:12 PM Pavel Machek wrote: > 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. 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Changes in sleep mode, on x86 PC 2016-03-29 13:06 ` Rafael J. Wysocki @ 2016-03-29 14:00 ` Oliver Neukum 2016-03-29 14:15 ` Pavel Machek 2016-03-29 14:24 ` Pavel Machek 1 sibling, 1 reply; 9+ messages in thread From: Oliver Neukum @ 2016-03-29 14:00 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Pavel Machek, kernel list, lenb, linux-acpi, Linux PM list, Jiri Kosina On Tue, 2016-03-29 at 15:06 +0200, Rafael J. Wysocki wrote: > On Monday, March 28, 2016 11:20:12 PM Pavel Machek wrote: > > 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. > > That's rather important. > > Clearly, something in the USB HID land has changed lately. Not necessarily. ACPI may also be the root cause. > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Changes in sleep mode, on x86 PC 2016-03-29 14:00 ` Oliver Neukum @ 2016-03-29 14:15 ` Pavel Machek 0 siblings, 0 replies; 9+ messages in thread From: Pavel Machek @ 2016-03-29 14:15 UTC (permalink / raw) To: Oliver Neukum Cc: Rafael J. Wysocki, kernel list, lenb, linux-acpi, Linux PM list, Jiri Kosina Hi! On Tue 2016-03-29 16:00:09, Oliver Neukum wrote: > On Tue, 2016-03-29 at 15:06 +0200, Rafael J. Wysocki wrote: > > On Monday, March 28, 2016 11:20:12 PM Pavel Machek wrote: > > > 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. > > > 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. > > 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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Changes in sleep mode, on x86 PC 2016-03-29 13:06 ` Rafael J. Wysocki 2016-03-29 14:00 ` Oliver Neukum @ 2016-03-29 14:24 ` Pavel Machek 2016-03-29 21:46 ` Rafael J. Wysocki 1 sibling, 1 reply; 9+ messages in thread From: Pavel Machek @ 2016-03-29 14:24 UTC (permalink / raw) To: Rafael J. Wysocki Cc: kernel list, lenb, linux-acpi, Linux PM list, Jiri Kosina On Tue 2016-03-29 15:06:36, Rafael J. Wysocki wrote: > On Monday, March 28, 2016 11:20:12 PM Pavel Machek wrote: > > 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. > > 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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Changes in sleep mode, on x86 PC 2016-03-29 14:24 ` Pavel Machek @ 2016-03-29 21:46 ` Rafael J. Wysocki 2016-03-29 21:56 ` Pavel Machek 0 siblings, 1 reply; 9+ messages in thread From: Rafael J. Wysocki @ 2016-03-29 21:46 UTC (permalink / raw) To: Pavel Machek; +Cc: kernel list, lenb, linux-acpi, Linux PM list, Jiri Kosina On Tuesday, March 29, 2016 04:24:05 PM Pavel Machek wrote: > > On Tue 2016-03-29 15:06:36, Rafael J. Wysocki wrote: > > On Monday, March 28, 2016 11:20:12 PM Pavel Machek wrote: > > > 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. > > > > 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? Generally, power/wakeup files under the involved devices (ie. if they are present and what's in them if so). Thanks, Rafael ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Changes in sleep mode, on x86 PC 2016-03-29 21:46 ` Rafael J. Wysocki @ 2016-03-29 21:56 ` Pavel Machek 2016-03-29 22:04 ` Rafael J. Wysocki 0 siblings, 1 reply; 9+ messages in thread From: Pavel Machek @ 2016-03-29 21:56 UTC (permalink / raw) To: Rafael J. Wysocki, oneukum Cc: kernel list, lenb, linux-acpi, Linux PM list, Jiri Kosina On Tue 2016-03-29 23:46:23, Rafael J. Wysocki wrote: > On Tuesday, March 29, 2016 04:24:05 PM Pavel Machek wrote: > > > > On Tue 2016-03-29 15:06:36, Rafael J. Wysocki wrote: > > > On Monday, March 28, 2016 11:20:12 PM Pavel Machek wrote: > > > > 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. > > > > > > 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? > > 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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Changes in sleep mode, on x86 PC 2016-03-29 21:56 ` Pavel Machek @ 2016-03-29 22:04 ` Rafael J. Wysocki 2016-03-30 14:48 ` Alan Stern 0 siblings, 1 reply; 9+ messages in thread From: Rafael J. Wysocki @ 2016-03-29 22:04 UTC (permalink / raw) To: Pavel Machek Cc: oneukum, kernel list, lenb, linux-acpi, Linux PM list, Jiri Kosina On Tuesday, March 29, 2016 11:56:45 PM Pavel Machek wrote: > > On Tue 2016-03-29 23:46:23, Rafael J. Wysocki wrote: > > On Tuesday, March 29, 2016 04:24:05 PM Pavel Machek wrote: > > > > > > On Tue 2016-03-29 15:06:36, Rafael J. Wysocki wrote: > > > > On Monday, March 28, 2016 11:20:12 PM Pavel Machek wrote: > > > > > 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. > > > > > > > > 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? > > > > 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? 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Changes in sleep mode, on x86 PC 2016-03-29 22:04 ` Rafael J. Wysocki @ 2016-03-30 14:48 ` Alan Stern 0 siblings, 0 replies; 9+ messages in thread From: Alan Stern @ 2016-03-30 14:48 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Pavel Machek, oneukum, kernel list, lenb, linux-acpi, Linux PM list, Jiri Kosina On Wed, 30 Mar 2016, Rafael J. Wysocki wrote: > On Tuesday, March 29, 2016 11:56:45 PM Pavel Machek wrote: > > > > On Tue 2016-03-29 23:46:23, Rafael J. Wysocki wrote: > > > On Tuesday, March 29, 2016 04:24:05 PM Pavel Machek wrote: > > > > > > > > On Tue 2016-03-29 15:06:36, Rafael J. Wysocki wrote: > > > > > On Monday, March 28, 2016 11:20:12 PM Pavel Machek wrote: > > > > > > 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. > > > > > > > > > > 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? > > > > > > 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? > > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2016-03-30 14:48 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-03-28 21:20 Changes in sleep mode, on x86 PC Pavel Machek 2016-03-29 13:06 ` Rafael J. Wysocki 2016-03-29 14:00 ` Oliver Neukum 2016-03-29 14:15 ` Pavel Machek 2016-03-29 14:24 ` Pavel Machek 2016-03-29 21:46 ` Rafael J. Wysocki 2016-03-29 21:56 ` Pavel Machek 2016-03-29 22:04 ` Rafael J. Wysocki 2016-03-30 14:48 ` Alan Stern
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox