Kernel Bug Tracker – Bug 14365
resume from suspend to ram broken after suspend to disk - Thinkpad T61
Last modified: 2011-04-19 07:51:35 UTC
I have a problem on my T61, running 2.6.31.
- login to desktop
- boot, resume to desktop
- try to resume
At that time, when opening the LID, or pressing the Fn key to resume the laptop, the moon blinks once and then stays lighted on, and nothing happens. I can't do anything except pressing the power button for 4 seconds to switch off the laptop.
It happens since quite some time (at least 2.6.26, I guess), I don't think it ever worked correctly.
Do you use s2disk for hibernation?
No, I hibernate from hal which in turns runs pm-hibernate which uses:
echo disk > /sys/power/state
Please try doing 'echo shutdown > /sys/power/disk' before hibernation and see if suspend is still broken after that (please do it after a clean boot).
It didn't work, same thing happens.
Please try "simulated hibernation" with
echo core > /sys/power/pm_test
echo disk > /sys/power/state
(this will sleep for at least 5 seconds)
echo none > /sys/power/pm_test
and see if suspend to RAM works after that.
I don't have any /sys/power/pm_test
I guess I need to rebuild a 2.6.31 with some debugging options enabled?
Yes. CONFIG_PM_DEBUG has to be set to 'y' for this purpose.
(In reply to comment #5)
> Please try "simulated hibernation" with
> echo core > /sys/power/pm_test
> echo disk > /sys/power/state
> (this will sleep for at least 5 seconds)
In fact it didn't really “sleep”. It started a suspend to disk, shrunk the memory etc. but didn't stop the machine. Then it started resuming to normal desktop.
> echo none > /sys/power/pm_test
> and see if suspend to RAM works after that.
After that, the suspend to ram went fine, and resumed fine.
Will you please do the following suspend/resume test after hibernation?
1. dmesg >dmesg_before;
2. echo mem > /sys/power/state; dmesg >dmesg_after; sync;
3. after the system enters the sleeping state, press the power button and see whether the system can be resumed.
4. If it can't be resumed, please reboot the box and check whether the file of dmesg_after is created. If it is created, please attach the files of dmesg_before, dmesg_after.
Please attach the output of acpidump, lspci -vxxx.
Created attachment 23362 [details]
(In reply to comment #9)
> Hi, Yves-alexis
> Will you please do the following suspend/resume test after hibernation?
> 1. dmesg >dmesg_before;
> 2. echo mem > /sys/power/state; dmesg >dmesg_after; sync;
> 3. after the system enters the sleeping state, press the power button and
> see whether the system can be resumed.
> 4. If it can't be resumed, please reboot the box and check whether the file
> of dmesg_after is created. If it is created, please attach the files of
> dmesg_before, dmesg_after.
dmesg_after is never created.
I noticed that, at one point, I managed to get a working machine after the second resume, but was never able to reproduce it, so I don't know what happened at that time. But I do have the resume_after for this one so I'm attaching it just in case.
Created attachment 23363 [details]
dmesg before first hibernation
Created attachment 23364 [details]
dmesg after first hibernation, before first suspend
Created attachment 23365 [details]
dmesg after second hibernation and second suspend
please use "echo mem/disk > /sys/power/state" to suspend/hibernate, and use power button to resume, instead of Lid/Fn keys.
does the problem still exist?
bug closed as there is no response from the bug reporter.
please re-open it if the problem still exists in the latest upstream kernel.