This happens on a Vaio VGN-NW130D laptop running Debian testing. Resuming from suspend works fine under kernels up to 2.6.34, but I get a full restart (most of the time, not always) under 2.6.35 and 2.6.36. I don't use any proprietary drivers, but I do have the Debian package firmware-linux-nonfree installed. How could I help trace the problem? Thank you, Adriano
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