My ThinkPad T420 can be wake up by just pressing enter at the external USB keyboard if it was s2ram'ed before. Works fine in 3.9.4 but with 3.10-rc3 I'M forced to open the LID to wake up the system.
Please provide the output of acpidump and lsusb. Could you do a bisect to find which commit causes this issue?
Created attachment 103001 [details] acpidump.3.10.0-rc3+ # cat lsusb.3.10.0-rc3+ Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 1bcf:0c31 Sunplus Innovation Technology Inc. SPIF30x Serial-ATA bridge Bus 001 Device 004: ID 0a5c:217f Broadcom Corp. BCM2045B (BDC-2.1) Bus 001 Device 005: ID 04f2:b221 Chicony Electronics Co., Ltd integrated camera Bus 002 Device 003: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB Bus 002 Device 004: ID 17ef:1003 Lenovo Integrated Smart Card Reader Bus 002 Device 005: ID 046d:c062 Logitech, Inc. M-UAS144 [LS1 Laser Mouse] Bus 002 Device 006: ID 043d:0078 Lexmark International, Inc. InkJet Color Printer Bus 002 Device 007: ID 046a:0023 Cherry GmbH CyMotion Master Linux Keyboard G230 acpidump is attached Bisecting is the 2nd best choice (b/c it can't be automated, therefore at least narrowing down the issue to a path/file would be appreciated)
Please provide "lsusb -t", "lspci" and dmesg after wakeup by Lid. check whether "/sys/devices/(pci ehci, root hub, usb keyboard)/power/wakeup" is enabled.
Created attachment 103011 [details] dmesg
$ /usr/sbin/lspci 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04) 00:16.3 Serial controller: Intel Corporation 6 Series/C200 Series Chipset Family KT Controller (rev 04) 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04) 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b4) 00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 (rev b4) 00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b4) 00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b4) 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation QM67 Express Chipset Family LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller (rev 04) 00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 04) 03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 34) 0d:00.0 System peripheral: Ricoh Co Ltd PCIe SDXC/MMC Host Controller (rev 05) tfoerste@n22 ~ $ /usr/sbin/lspci -t -[0000:00]-+-00.0 +-02.0 +-16.0 +-16.3 +-19.0 +-1a.0 +-1b.0 +-1c.0-[02]-- +-1c.1-[03]----00.0 +-1c.3-[05-0c]-- +-1c.4-[0d]----00.0 +-1d.0 +-1f.0 +-1f.2 \-1f.3 $ cat enabled-after.3.10.0-rc3+ /sys/devices/pnp0/00:06/power/wakeup:enabled /sys/devices/pci0000:00/0000:00:1a.0/power/wakeup:enabled /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2.3/power/wakeup:enabled /sys/devices/pci0000:00/0000:00:1d.0/power/wakeup:enabled /sys/devices/LNXSYSTM:00/device:00/PNP0C0D:00/power/wakeup:enabled /sys/devices/LNXSYSTM:00/device:00/PNP0C0E:00/power/wakeup:enabled /sys/devices/LNXSYSTM:00/LNXPWRBN:00/power/wakeup:enabled
Created attachment 103061 [details] debug.patch Please try this patch.
(In reply to comment #6) > Please try this patch. issue does still exist
FWIW after s2ram the temperature goes high to 80-90° (I'm using cpu governor ondemand,and CPU speed is set to max frequency), after few runs of my script to change settings of the ondemand governor the system comes back to low temperature and frequency) - might be a different issue however
Please provide the output of dmesg with patch in the comment #6.
Created attachment 103111 [details] dmesg after s2ram (In reply to comment #6) > Created an attachment (id=103061) [details] > debug.patch > > Please try this patch. (In reply to comment #9) > Please provide the output of dmesg with patch in the comment #6.
Currently, there are not more clue. One issue I found have fixed by my patch in the comment #6. The Bios does't provide ehci D3hot support but the ehci's aml method _S3D and _PRW indicate it can put into D3hot during S3(system suspend). This maybe the cause but ... So please try bisect. Sorry. Before [ 3585.301174] PM: late suspend of devices complete after 0.266 msecs [ 3585.312925] ehci-pci 0000:00:1d.0: System wakeup enabled by ACPI [ 3585.312934] ehci-pci 0000:00:1d.0: power state changed by ACPI to D2 [ 3585.313335] ehci-pci 0000:00:1a.0: System wakeup enabled by ACPI [ 3585.313340] ehci-pci 0000:00:1a.0: power state changed by ACPI to D2 [ 3585.323865] PM: noirq suspend of devices complete after 22.692 msecs [ 3585.324526] ACPI: Preparing to enter system sleep state S3 After [ 94.538019] PM: late suspend of devices complete after 0.263 msecs [ 94.549711] ehci-pci 0000:00:1d.0: System wakeup enabled by ACPI [ 94.560538] ehci-pci 0000:00:1d.0: power state changed by ACPI to D3hot [ 94.560945] ehci-pci 0000:00:1a.0: System wakeup enabled by ACPI [ 94.571521] ehci-pci 0000:00:1a.0: power state changed by ACPI to D3hot [ 94.582622] PM: noirq suspend of devices complete after 44.612 msecs
(In reply to comment #11) > Currently, there are not more clue. One issue I found have fixed by my patch > in > the comment #6. > The Bios does't provide ehci D3hot support but the ehci's aml method _S3D and > _PRW indicate it can put into D3hot during S3(system suspend). This maybe the > cause but ... So please try bisect. Sorry. No problem - thx for your help. BTW I'd first address the CPU governor in another bug report.
Created attachment 104741 [details] .config bisected (and FWIW) again: I do boot from an external USB 2.0 drive): commit 0aa2832dd0d9d8609fd8f15139bc7572541a1215 Author: Alan Stern <stern@rowland.harvard.edu> Date: Wed Mar 27 16:14:19 2013 -0400 USB: use "global suspend" for system sleep on USB-2 buses This patch (as1674) speeds up system sleep transitions by not suspending each individual device on a USB-1.1 or USB-2 bus. The devices will automatically go into suspend when their root hubs are suspended (i.e., stop sending out Start-Of-Frame packets) -- this is what the USB spec calls "global suspend". Since this is what we do already when CONFIG_USB_SUSPEND isn't enabled, it shouldn't cause any problems.
Have you checked that reverting this commit fixes the problem?
(In reply to comment #14) > Have you checked that reverting this commit fixes the problem? Can't be tested on top of the current git tree : $ git show 0aa2832 | patch -p1 -R --dry-run patching file drivers/usb/core/hub.c Hunk #1 FAILED at 2886. 1 out of 4 hunks FAILED -- saving rejects to file drivers/usb/core/hub.c.rej and against the previous was already made during bisect, right ?
(In reply to comment #14) > Have you checked that reverting this commit fixes the problem? and I double-checked it again - it is that commit - definitely.
Okay; I just wanted to make sure. I have seen several cases where bisection ended up identifying the wrong commit. What happens if you check out the commit preceding this one, and then build the kernel with CONFIG_USB_SUSPEND disabled? As far as I can see, the effect of the 0aa2832 coomit should be pretty much the same as running without CONFIG_USB_SUSPEND. If true, this means that the problem existed all along and the commit merely made it more visible.
Oops, I was wrong. Looking back at the old code, it turns out that without CONFIG_USB_SUSPEND we never enable USB wakeup at all. It could be that your problem is related to the 4-port hub the keyboard is plugged into. Can you try plugging the keyboard directly into the computer to see if it makes any difference? If that still doesn't work, perhaps you could collect a pair of usbmon traces: one showing what happens on bus 2 with the commit applied, and the other showing the same thing but with the commit not present. One more thing: Can you post the output from "lspci -vv -s 1d.0" (run as root)?
well, it is not the hub. # lspci -vv -s 1d.0 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) (prog-if 20 [EHCI]) Subsystem: Lenovo Device 21ce Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 23 Region 0: Memory at f2529000 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Debug port: BAR=1 offset=00a0 Capabilities: [98] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel driver in use: ehci-pci related to usbmon, which commands do you want to run me ?
The lspci output shows that the EHCI controller supports D3hot but not D2, so Lan Tianyu's patch is a step in the right direction. For usbmon, before starting the suspend, do: cat /sys/kernel/debug/usb/usbmon/2u >filename After the resume, kill the "cat" process with ^C. The trace will be recorded in the file whose name you specified. (The kernel needs to have CONFIG_DEBUG_FS and CONFUG_USB_MON enabled.) Another thing you can do: Build a kernel with CONFIG_USB_DEBUG enabled, and attach the dmesg log from that kernel showing what happens during a suspend/resume cycle where you try to use the keyboard to wake up the system.
Created attachment 104781 [details] 2u log
Created attachment 104791 [details] dmesg after s2ram keyboard don't work, open and close lid however worked
Were the last two attachments made with the commit present? Assuming it was, please do the same thing with the commit removed. Both the dmesg and usbmon logs indicate that the keyboard did do something, because its port was disabled when the system resumed. The same was not true of the 4-port hub; I'm not sure what that means, if anything. One more thing you can try is to turn on the wakeup attribute for the usb2, 2-1, and 2-1.2 devices before suspending. Again, I don't know if that will make any difference. In theory it shouldn't, but in reality you never know.
Created attachment 104801 [details] 2u log keyboard worked keyboard worked after 0aa2832 was reverted on top of tree 0aa2832
Created attachment 104811 [details] dmesg after s2ram keyboard worked keyboard worked after 0aa2832 was reverted on top of tree 0aa2832
Created attachment 104991 [details] suspend root-hub ports but not others The logging doesn't tell me anything new, unfortunately. So it's time for more direct experiments. The attached patch will cause the system to behave partly in between the pre-commit and post-commit systems: the built-in hub will be suspended explicitly but the 4-port hub won't be. Let's see what the usbmon and dmesg logs show with this patch.
Created attachment 105001 [details] 2u log + debug-wakeup-failure.patch patch applied on top of v3.10-rc6-1-g8177a9d - bug still there
Created attachment 105011 [details] dmesg + debug-wakeup-failure.patch corresponding dmesg
Created attachment 105061 [details] Suspend ports for hubs but not other devices Still no good. All right, try out this patch instead. It will explicitly suspend the ports for both hubs, but not for the keyboard.
Created attachment 105071 [details] 2u log + debug-wakeup-failure-2.patch still no luck with -2 patch
Created attachment 105081 [details] dmesg + debug-wakeup-failure-2.patch dmesg
Created attachment 105091 [details] Suspend non-hub ports There's still no wakeup signal from the keyboard. This indicates that the problem may lie in the keyboard itself rather than in any of the hubs. Or maybe there's a weird interaction between the keyboard and the 4-port hub. This version of the debug patch will treat the keyboard like the pre-commit system, while treating the hubs like the post-commit system.
Created attachment 105101 [details] 2u log + debug-wakeup-failure-3.patch (In reply to comment #32) > Created an attachment (id=105091) [details] > This version of the debug patch will treat the keyboard like the pre-commit > system, while treating the hubs like the post-commit system. issue solved
Created attachment 105111 [details] dmesg + debug-wakeup-failure-3.patch
It would be more accurate to say the issue has been located. The patch you tried was just for debugging; it isn't a solution. There's another test I'd like you to try, involving a different sort of wakeup signal. This time, before starting the suspend, do echo enabled >/sys/bus/usb/devices/2-1.2/power/wakeup Then, when the system is asleep, don't try to wake it up by typing on the keyboard. Instead, unplug the keyboard cable from the 4-port hub. Try doing this with the debug-wakeup-failure-3 patch installed and then again without the patch (both times with commit 0aa2832 present). You don't need to post usbmon traces; the dmesg logs will be enough. You can remove a bunch of unnecessary stuff from the beginning of the logs by doing "dmesg -C" before starting the suspend.
Created attachment 105221 [details] dmesg + debug-wakeup-failure-3.patch + echo enabled with your debug patch on top of the commit unplug the keyboard cable from the 4-port hub wake up the system
Created attachment 105231 [details] dmesg + echo enabled again - unplug the keyboard woke up the system (BTW I always choosed git tree v3.10-rc6-1-g8177a9d for this and the test before)
It turns out that I have a 4-port hub with the same vendor and product IDs as yours. I tried running your tests (using a mouse, not a keyboard), and the results were the same as you got. I need to run some more tests tomorrow, but it definitely looks like the hub is buggy. This isn't surprising; we have known for a long time that hardware from Genesys Logic tends to be unreliable. At this point I'm more curious about what happens when you remove the 4-port hub and plug the keyboard into the port that the hub was using. Do you still see the same pattern of wakeup failures and successes?
(In reply to comment #38) > At this point I'm more curious about what happens when you remove the 4-port > hub and plug the keyboard into the port that the hub was using. Do you still > see the same pattern of wakeup failures and successes? updated in the mean while to v3.10-rc6-60-g17858ca - hoping, that doesn't affect the test result - that without a hub neither pressing a key nor unplug/plug wakeup the system - I have to open/close the LID.
BTW - although this is now discussed in the mailing list - I realized today, that I do have an USB port on the ThinkPad where even with the given patch at the ML the system does not wakeup. I tis the same port from which I cannot wakeup a system reliable if I booted over that port from an external USB 2.0 drive a linux and s2ram'ed it.
Is that non-working port the one where the hub is plugged in? I tried running some tests on my equipment and got some interesting results. Let's see if your equipment behaves the same way. These tests should be performed on an unpatched kernel. For the first experiment, unplug the 4-port hub and plug the keyboard into the port the hub was using. Then do: echo enabled >/sys/bus/usb/devices/2-1/power/wakeup and see if the keyboard will wake up the system. For the second experiment, put the hub and cables back the way they were, and do: echo enabled >/sys/bus/usb/devices/2-1/power/wakeup echo enabled >/sys/bus/usb/devices/2-1.2/power/wakeup and see if the keyboard will wake up the system.
Created attachment 106511 [details] dmesg kernel 3.10, the first part let the system immediately wakeup : n22 ~ # lsusb Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 1bcf:0c31 Sunplus Innovation Technology Inc. SPIF30x Serial-ATA bridge Bus 001 Device 004: ID 0a5c:217f Broadcom Corp. BCM2045B (BDC-2.1) Bus 001 Device 005: ID 04f2:b221 Chicony Electronics Co., Ltd integrated camera Bus 002 Device 009: ID 046d:c062 Logitech, Inc. M-UAS144 [LS1 Laser Mouse] Bus 002 Device 008: ID 046a:0023 Cherry GmbH CyMotion Master Linux Keyboard G230 Bus 002 Device 004: ID 17ef:1003 Lenovo Integrated Smart Card Reader n22 ~ # cat /sys/bus/usb/devices/2-1/power/wakeup disabled n22 ~ # cat /sys/bus/usb/devices/2-1.2/power/wakeup enabled n22 ~ # echo enabled >/sys/bus/usb/devices/2-1/power/wakeup n22 ~ # Fn4 * WARNING: net.ppp0 is already stopped <---- here the system comes back immediately so no chance to test the keyboard n22 ~ # cat /sys/bus/usb/devices/2-1/power/wakeup enabled n22 ~ # cat /sys/bus/usb/devices/2-1.2/power/wakeup enabled for the 2nd I do have the samw picture, the system doesn't stay in sleep mode