Bug 23002

Will you please firstly confirm whether it can be resumed under the following tests?
    1. echo freezer > pm_test
    2. echo mem > /sys/power/state
    3. wait for some time and see whether it can be resumed correctly
    4. if it can be resumed, please try to echo "devices/platform/processors/core" one by one > pm_test and repeat the step 2/3 again.

If it still can be resumed correctly, maybe you will have to use the git-bisect to identify which commit causes the regression.

Thanks.

Hi,

Thanks for your reply.

Yes, the laptop resumes under all tests (freezer, devices, platform, processors, core) both with kernels 2.6.32 and 2.6.36 (these are the versions I have installed right now). However, under both kernel versions, I get a totally corrupted window once the computer resumes (except when using freezer), so that I have to reboot the machine in order to get a usable screen again (did I just hit another bug?). However, under 2.6.36, the problem persists: when suspending the computer using KDE's powerdevil and trying to resume, I get a full reboot right away.

If I do need to use git-bisect to pinpoint the offending commit, where can I find help on how to do that?

Thanks a lot for your help,

Adriano

Hello,

So, I ran git-bisect between versions 2.6.34 and 2.6.35 and, after lots of testing and dozens and dozens of reboots, I managed to identify the commit that introduced the regression:

2a6b69765ad794389f2fc3e14a0afa1a995221c2 is the first bad commit
commit 2a6b69765ad794389f2fc3e14a0afa1a995221c2
Author: Matthew Garrett <mjg@redhat.com>
Date:   Fri May 28 16:32:15 2010 -0400

    ACPI: Store NVS state even when entering suspend to RAM

    https://bugzilla.kernel.org/show_bug.cgi?id=13931 describes a bug where
    a system fails to successfully resume after the second suspend. Maxim
    Levitsky discovered that this could be rectified by forcibly saving
    and restoring the ACPI non-volatile state. The spec indicates that this
    is only required for S4, but testing the behaviour of Windows by adding
    an ACPI NVS region to qemu's e820 map and registering a custom memory
    read/write handler reveals that it's saved and restored even over suspend
    to RAM. We should mimic that behaviour to avoid other broken platforms.

    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

:040000 040000 6c1127ac1a761c682c5ff6bfcfe749852a81f490 a45351dda648929909f75ffa306a4e7c56c5a614 M	drivers


This was very hard to find because the problem doesn't always happen. Apparently, it only occurs when the battery is charging, not when it is fully charged (power cord plugged) or when it is discharging (power cord unplugged). Furthermore, I noticed that, even with the battery charging, if I boot a good kernel and then reboot into a bad kernel, resuming works.

I hope this information is useful in trying to fix this problem. Please, let me know if I need to do any more testing.

Thank you,

Adriano

Please attach the output of dmidecode for that box.

Created attachment 39462 [details]
dmidecode output

I have 3 user reports complaining about their VAIO which restarts instead of shutting down on 2.6.36. They say that 2.6.36_rc7 was fine. It's interesting that both bugs occurs on VAIO. Is there a correlation between bugs or should I create a new report for the reboot/halt problem?

Please file a new report for the reboot/halt issue.  If 2.6.36-rc7 was fine,
perhaps one of the affected users will be able to identify the commit that
introduced the issue?

Created attachment 39672 [details]
ACPI / PM: Do not save/restore NVS on Sony Vaio VGN-NW130D

Please verify if this patch (on top of the current Linus' tree) fixes your
resume problem.

Yes, this patch fixes the problem on my machine. I have noticed a couple of blacklisted machines working around commit 2a6b69765ad794389f2fc3e14a0afa1a995221c2 in the file drivers/acpi/sleep.c, which makes me wonder if it doesn't create more problems than it fixes...

Thanks a lot for your help.

patch in comment #8 applied to acpi tree.

yes, we wonder the same thing.

shipped in 2.6.37-rc6
closed