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.
Please attach dmesg output generated right after a failing attempt to suspend (after a successful one and resume).
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
I actually meant 1. boot with break=top (not with break=modules) in the comment of the dmesg attachment, sorry.
I feel like maybe I should change the NEEDINFO status, but no alternative seems suitable. Do I overlook something?
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.
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.
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.
Can you try "echo LID > /proc/acpi/wakeup" before the second suspend and see if that helps?
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).
This appears to be an ACPI issue.
It looks like we should clear something after the first (successful) resume, but I have no idea what it is at the moment.
Created attachment 45912 [details] Reset sleep button status on resume Please check if this patch makes a difference.
Unfortunately the patch doesn't make any difference.
Does it work if you disable both LID and SLPB after the first resume and then enable them right before the next suspend?
Is the ACPI button driver loaded on your system?
please attach the dmesg and /proc/acpi/wakeup for the working 2.6.32
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...
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.
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.
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.
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?
Vanilla 2.6.32.28 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?
9630bdd9b15d2f489c646d8bc04b60e53eb5ec78 is the first bad commit commit 9630bdd9b15d2f489c646d8bc04b60e53eb5ec78 Author: Rafael J. Wysocki <rjw@sisk.pl> 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 <mjg@redhat.com>. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> :040000 040000 cf2b1f5e0d0c9fb9d6766b6408ef8203061870e9 e5d1a14b3b0401d7a48623e5d7dc4eee7cbbe4a7 M drivers :040000 040000 21b988e2dc3f9e252aa2072a880caa030bfc84ff d02b0d6e31d9f0a1d7fcac2b6e30a1b96c805c37 M include
I was afraid it was this one, but thanks for the confirmation.
Please attach the output of /proc/ioports .
Also please attach the output of acpidump from your machine.
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).
Created attachment 46292 [details] contents of /proc/ioports (under fully booted 2.6.37)
Created attachment 46302 [details] acpidump output
I tried attachment 46232 [details] on 2.6.38-rc3, unfortunately it didn't help.
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.
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.
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).
(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!
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.
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.
Please also attach the output of the following command: $ egrep 'enabled|disabled' /sys/firmware/acpi/interrupts/gpe* before suspend and after the subsequent resume.
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!
Created attachment 46592 [details] output of egrep 'enabled|disabled' /sys/firmware/acpi/interrupts/gpe*
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.
That appears to confirm my theory, thanks a lot!
merged in 2.6.38-rc5: commit 2a5d24286e8bdafdc272b37ec5bdd9e977b3767c Author: Rafael J. Wysocki <rjw@sisk.pl> Date: Sat Feb 12 01:39:53 2011 +0100 ACPI / Wakeup: Enable button GPEs unconditionally during initialization