Description Ferenc Wágner 2011-01-22 22:44:56 UTC
Created attachment 44802 [details] config of an affected 2.6.37 kernel If I boot my ThinkPad R50e with a fairly stock kernel (vanilla 2.6.37 with Debian config) with break=top (to get a prompt in the early initramfs phase, before any modules are loaded), I can successfully suspend to RAM via "echo mem >/sys/power/state", but only once. Further tries don't power off the machine but resume instantly and give the prompt back without any error indication. If (after a reboot) I "echo core >/sys/power/pm_test", then any number of "echo mem >/sys/power/state" commands wait 5 seconds before resuming. If I then "echo none >/sys/power/pm_test; echo mem >/sys/power/state", then the machine suspends all right once, but repeated "echo mem >/sys/power/state" commands again fail to put the machine into low power state (S3). The same happens under 2.6.36 as well, but 2.6.32 seems to work OK on repeated suspends. I can try to narrow it down unless some better idea surfaces.
Comment 1 Rafael J. Wysocki 2011-01-22 23:08:17 UTC
Please attach dmesg output generated right after a failing attempt to suspend (after a successful one and resume).
Comment 2 Ferenc Wágner 2011-01-23 10:28:51 UTC
Created attachment 44832 [details] dmesg after a failed suspend Steps taken: 1. boot with break=modules 2. (initramfs) echo mem >/sys/power/state 3. wait a minute before waking up the system 4. wait a minute after resume at the (initramfs) prompt 5. (initramfs) echo mem >/sys/power/state 6. the system doesn't sleep but comes back instantly 7. save dmesg 8. continue booting 9. attach the saved dmesg here
Comment 3 Ferenc Wágner 2011-01-23 10:35:57 UTC
I actually meant 1. boot with break=top (not with break=modules) in the comment of the dmesg attachment, sorry.
Comment 4 Ferenc Wágner 2011-01-24 18:14:02 UTC
I feel like maybe I should change the NEEDINFO status, but no alternative seems suitable. Do I overlook something?
Comment 5 Rafael J. Wysocki 2011-01-30 14:00:41 UTC
OK, so I can see that the machine has actually suspended, but it was woken up immediately after that. Can you try the same thing with 2.6.38-rc3, when it's out, and see if the problem continues? If it does, please attach the contents of /proc/acpi/wakeup read before the first (successful) suspend and before the next (unsuccessful) one.
Comment 6 Ferenc Wágner 2011-02-01 14:55:54 UTC
Created attachment 45762 [details] dmesg after the second (instanty resumed) suspend under 2.6.38-rc3 Unfortunately, the problem persists under 2.6.38-rc3 in the exact same form as under 2.6.37: the first suspend works OK, but the second resumes instantly.
Comment 7 Ferenc Wágner 2011-02-01 14:59:08 UTC
Created attachment 45772 [details] contents of /proc/acpi/wakeup under 2.6.38-rc3 The contents of /proc/acpi/wakeup didn't change between the suspend attempts, ie. it was exactly the same after the fresh reboot, after the first (successful) suspend and resume and after the second (automatically instantly resumed) suspend attempt.
Comment 8 Rafael J. Wysocki 2011-02-01 18:30:04 UTC
Can you try "echo LID > /proc/acpi/wakeup" before the second suspend and see if that helps?
Comment 9 Ferenc Wágner 2011-02-01 19:46:28 UTC
No, it does not help. However, when teamed with "echo SLPB >/proc/acpi/wakeup", it helps! Basically, if I resume the computer with the power button, then repeated suspend works. But as soon as I resume either with the lid or with the sleep button, further suspends don't work (that is, instantly resume) unless both the LID and the SLPB wakeup is disabled (which means that every wakeup source in /proc/acpi/wakeup is disabled).
Comment 10 Rafael J. Wysocki 2011-02-01 20:40:50 UTC
This appears to be an ACPI issue.
Comment 11 Rafael J. Wysocki 2011-02-01 20:53:46 UTC
It looks like we should clear something after the first (successful) resume, but I have no idea what it is at the moment.
Comment 12 Rafael J. Wysocki 2011-02-01 21:23:07 UTC
Created attachment 45912 [details] Reset sleep button status on resume Please check if this patch makes a difference.
Comment 13 Ferenc Wágner 2011-02-02 21:08:16 UTC
Unfortunately the patch doesn't make any difference.
Comment 14 Rafael J. Wysocki 2011-02-02 22:39:07 UTC
Does it work if you disable both LID and SLPB after the first resume and then enable them right before the next suspend?
Comment 15 Rafael J. Wysocki 2011-02-02 22:53:27 UTC
Is the ACPI button driver loaded on your system?
Comment 16 Len Brown 2011-02-02 23:13:39 UTC
please attach the dmesg and /proc/acpi/wakeup for the working 2.6.32
Comment 17 Ferenc Wágner 2011-02-02 23:22:43 UTC
I tried this: (initramfs) echo mem >/sys/power/state [wake up computer via Fn, which is the sleep button] (initramfs) echo LID >/proc/acpi/wakeup (initramfs) echo SLPB >/proc/acpi/wakeup [now everything is *disabled in /proc/acpi/wakeup] (initramfs) echo LID enable >/proc/acpi/wakeup (initramfs) echo SLPB enable >/proc/acpi/wakeup [we're back to the original state of /proc/acpi/wakeup] (initramfs) echo mem >/sys/power/state which led to an instant automatic resume, exactly as without any /proc/acpi/wakeup dance. I hope this answers comment 14. Regarding comment 15: button.ko wasn't loaded during the above test (not a single module was). Of course it's normally loaded in a fully booted system. Rebooting for the 2.6.32 info...
Comment 18 Ferenc Wágner 2011-02-02 23:41:25 UTC
Created attachment 46152 [details] dmesg after the second (still successful) suspend under 2.6.32 As requested in comment 16, with the caveat that this kernel isn't vanilla 2.6.32, but the current Debian squeeze kernel. This is the only one I currently have access to. Hope the output is still useful.
Comment 19 Ferenc Wágner 2011-02-02 23:46:25 UTC
Created attachment 46162 [details] /proc/acpi/wakeup under 2.6.32 The only difference to the 2.6.38-rc3 version is the lack of asterisks (*) before the "disabled" words.
Comment 20 Rafael J. Wysocki 2011-02-03 18:36:11 UTC
Unfortunately, it doesn't give us any information allowing the problem to be narrowed down. Can you check if the 2.6.35.y kernels also have the problem? In the meantime, I'm going to prepare a patch or two for you to test.
Comment 21 Rafael J. Wysocki 2011-02-03 22:43:23 UTC
I've got a similar report where the problem is present in a kernel based on 2.6.32. Can you please verify if the issue is not present in the last 2.6.32.y kernel?
Comment 22 Ferenc Wágner 2011-02-04 11:59:52 UTC
Vanilla 188.8.131.52 doesn't exhibit this problem. AFAICT that's the latest. I'm starting a git bisect session now. Are you interested in a particular 2.6.35.y version?
Comment 23 Ferenc Wágner 2011-02-04 13:18:39 UTC
9630bdd9b15d2f489c646d8bc04b60e53eb5ec78 is the first bad commit commit 9630bdd9b15d2f489c646d8bc04b60e53eb5ec78 Author: Rafael J. Wysocki <firstname.lastname@example.org> Date: Wed Feb 17 23:41:07 2010 +0100 ACPI: Use GPE reference counting to support shared GPEs ACPI GPEs may map to multiple devices. The current GPE interface only provides a mechanism for enabling and disabling GPEs, making it difficult to change the state of GPEs at runtime without extensive cooperation between devices. Add an API to allow devices to indicate whether or not they want their device's GPE to be enabled for both runtime and wakeup events. Remove the old GPE type handling entirely, which gets rid of various quirks, like the implicit disabling with GPE type setting. This requires a small amount of rework in order to ensure that non-wake GPEs are enabled by default to preserve existing behaviour. Based on patches from Matthew Garrett <email@example.com>. Signed-off-by: Matthew Garrett <firstname.lastname@example.org> Signed-off-by: Rafael J. Wysocki <email@example.com> Signed-off-by: Jesse Barnes <firstname.lastname@example.org> :040000 040000 cf2b1f5e0d0c9fb9d6766b6408ef8203061870e9 e5d1a14b3b0401d7a48623e5d7dc4eee7cbbe4a7 M drivers :040000 040000 21b988e2dc3f9e252aa2072a880caa030bfc84ff d02b0d6e31d9f0a1d7fcac2b6e30a1b96c805c37 M include
Comment 24 Rafael J. Wysocki 2011-02-04 17:47:38 UTC
I was afraid it was this one, but thanks for the confirmation.
Comment 25 Rafael J. Wysocki 2011-02-04 18:16:23 UTC
Please attach the output of /proc/ioports .
Comment 26 Rafael J. Wysocki 2011-02-04 19:04:49 UTC
Also please attach the output of acpidump from your machine.
Comment 27 Rafael J. Wysocki 2011-02-04 19:44:36 UTC
Created attachment 46232 [details] ACPI / PM: Clear run/wake GPEs during wakeup Also, please check if this patch helps (on top of the current Linus' tree).
Comment 28 Ferenc Wágner 2011-02-04 22:42:33 UTC
Created attachment 46292 [details] contents of /proc/ioports (under fully booted 2.6.37)
Comment 30 Ferenc Wágner 2011-02-04 23:02:57 UTC
I tried attachment 46232 [details] on 2.6.38-rc3, unfortunately it didn't help.
Comment 31 Rafael J. Wysocki 2011-02-04 23:25:10 UTC
Created attachment 46322 [details] ACPI: Debug clearing and disabling of GPE blocks Thanks for the testing. Please apply this patch on top of 2.6.38-rc3 and carry out two suspend/resume cycles (one successful and one failing). Please attach the dmesg output generated after that.
Comment 32 Rafael J. Wysocki 2011-02-05 13:00:12 UTC
Created attachment 46462 [details] ACPI / Wakeup: Enable button GPEs unconditionally One of the things that we do differently after commit 9630bdd (ACPI: Use GPE reference counting to support shared GPEs) is that we don't enable button wakeup GPEs unconditionally in acpi_wakeup_device_init(). In theory, that may make a difference if the button driver is not loaded, because in that case the sleep button/lid GPE is disabled during resume and the _L18 method will not be executed. In turn, if _L18 is executed, it stores the value of \_SB.PCI0.LPC.EC.HWAK under \RRBF for _WAK to process. The attached patch makes the sleep button/lid GPE be always enabled, please test.
Comment 33 Ferenc Wágner 2011-02-05 15:23:02 UTC
The button part of attachment 46462 [details] (ACPI / Wakeup: Enable button GPEs unconditionally) didn't apply on 2.6.38-rc3, but "CONFIG_ACPI_BUTTON is not set" anyway in my tests. I'll try the new kernel tonight (when I get to the machine).
Comment 34 Rafael J. Wysocki 2011-02-05 17:37:23 UTC
(In reply to comment #33) > The button part of attachment 46462 [details] (ACPI / Wakeup: Enable button > GPEs > unconditionally) didn't apply on 2.6.38-rc3, Sorry about that, it's on top of my local tree that contains some additional patches. > but "CONFIG_ACPI_BUTTON is not set" anyway in my tests. Yes, the button part is not important here. > I'll try the new kernel tonight (when I get to the machine). Thanks!
Comment 35 Ferenc Wágner 2011-02-05 21:48:54 UTC
Created attachment 46482 [details] approximate ouput of "dmesg | grep acpi_hw" after two successful suspends The wakeup part of attachment 46462 [details] (ACPI / Wakeup: Enable button GPEs unconditionally) seems to fix this problem! I tested with the debug patch applied at the same time, but the almost allnoconfig test kernel wasn't able to save the dmesg to persistent storage, so I had to type in the filtered part from several screenshots. If you're still interested in the full and precise dmesg, please tell and I'll compile a new kernel with the needed features added.
Comment 36 Rafael J. Wysocki 2011-02-05 22:30:41 UTC
Created attachment 46492 [details] ACPI / Wakeup: Enable button GPEs unconditionally during initialization (In reply to comment #35) Thanks! > If you're still interested in the full and precise > dmesg, please tell and I'll compile a new kernel with the needed features > added. That shouldn't be necessary. It looks like we clear the GPE status of the sleep button/lid GPE during resume and your testing shows that the problem is related to the GPE being not enabled at run time. Please confirm that the attached patch on top of 2.6.38-rc3 (instead of both attachment 46462 [details] and attachment 46322 [details]) fixes the reported issue.
Comment 37 Rafael J. Wysocki 2011-02-05 23:39:56 UTC
Please also attach the output of the following command: $ egrep 'enabled|disabled' /sys/firmware/acpi/interrupts/gpe* before suspend and after the subsequent resume.
Comment 38 Ferenc Wágner 2011-02-06 10:12:34 UTC
I confirm that attachment 46492 [details] (ACPI / Wakeup: Enable button GPEs unconditionally during initialization) as a single patch over 2.6.38-rc3 fixes this issue. Thanks for your work!
Comment 39 Ferenc Wágner 2011-02-06 10:14:48 UTC
Created attachment 46592 [details] output of egrep 'enabled|disabled' /sys/firmware/acpi/interrupts/gpe*
Comment 40 Ferenc Wágner 2011-02-06 10:20:26 UTC
Comment on attachment 46592 [details] output of egrep 'enabled|disabled' /sys/firmware/acpi/interrupts/gpe* This is also hand-typed, but the pattern is simple: GPE 03,04,05,0B,0C and 0D are disabled and always 0. GPE 18 and 1C are enabled. GPE 18 increases by 1 and GPE 1C by 13 on each resume by the sleep button or the lid. GPE 18 stays the same and GPE 1C increases by 7 on each resume by the power button.
Comment 41 Rafael J. Wysocki 2011-02-06 11:31:41 UTC
That appears to confirm my theory, thanks a lot!