Bug 27372 - Only the first suspend to RAM works
Only the first suspend to RAM works
Status: CLOSED CODE_FIX
Product: ACPI
Classification: Unclassified
Component: Power-Sleep-Wake
All Linux
: P1 normal
Assigned To: Rafael J. Wysocki
:
Depends on:
Blocks: 7216
  Show dependency treegraph
 
Reported: 2011-01-22 22:44 UTC by Ferenc Wágner
Modified: 2011-02-20 00:14 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.37
Tree: Mainline
Regression: Yes


Attachments
config of an affected 2.6.37 kernel (121.76 KB, text/plain)
2011-01-22 22:44 UTC, Ferenc Wágner
Details
dmesg after a failed suspend (35.91 KB, text/plain)
2011-01-23 10:28 UTC, Ferenc Wágner
Details
dmesg after the second (instanty resumed) suspend under 2.6.38-rc3 (35.78 KB, text/plain)
2011-02-01 14:55 UTC, Ferenc Wágner
Details
contents of /proc/acpi/wakeup under 2.6.38-rc3 (309 bytes, text/plain)
2011-02-01 14:59 UTC, Ferenc Wágner
Details
Reset sleep button status on resume (765 bytes, patch)
2011-02-01 21:23 UTC, Rafael J. Wysocki
Details | Diff
dmesg after the second (still successful) suspend under 2.6.32 (27.85 KB, text/plain)
2011-02-02 23:41 UTC, Ferenc Wágner
Details
/proc/acpi/wakeup under 2.6.32 (309 bytes, text/plain)
2011-02-02 23:46 UTC, Ferenc Wágner
Details
ACPI / PM: Clear run/wake GPEs during wakeup (1.02 KB, patch)
2011-02-04 19:44 UTC, Rafael J. Wysocki
Details | Diff
contents of /proc/ioports (under fully booted 2.6.37) (1.43 KB, text/plain)
2011-02-04 22:42 UTC, Ferenc Wágner
Details
acpidump output (37.39 KB, application/octet-stream)
2011-02-04 22:44 UTC, Ferenc Wágner
Details
ACPI: Debug clearing and disabling of GPE blocks (1.72 KB, patch)
2011-02-04 23:25 UTC, Rafael J. Wysocki
Details | Diff
ACPI / Wakeup: Enable button GPEs unconditionally (1.72 KB, patch)
2011-02-05 13:00 UTC, Rafael J. Wysocki
Details | Diff
approximate ouput of "dmesg | grep acpi_hw" after two successful suspends (9.77 KB, text/plain)
2011-02-05 21:48 UTC, Ferenc Wágner
Details
ACPI / Wakeup: Enable button GPEs unconditionally during initialization (1.58 KB, patch)
2011-02-05 22:30 UTC, Rafael J. Wysocki
Details | Diff
output of egrep 'enabled|disabled' /sys/firmware/acpi/interrupts/gpe* (522 bytes, text/plain)
2011-02-06 10:14 UTC, Ferenc Wágner
Details

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 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?
Comment 23 Ferenc Wágner 2011-02-04 13:18:39 UTC
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
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 29 Ferenc Wágner 2011-02-04 22:44:05 UTC
Created attachment 46302 [details]
acpidump output
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!
Comment 42 Florian Mickler 2011-02-20 00:14:13 UTC
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

Note You need to log in before you can comment on or make changes to this bug.