Bug 14365
| Summary: | resume from suspend to ram broken after suspend to disk - Thinkpad T61 | ||
|---|---|---|---|
| Product: | Power Management | Reporter: | Yves-Alexis Perez (corsac) |
| Component: | Hibernation/Suspend | Assignee: | power-management_other |
| Status: | REJECTED INSUFFICIENT_DATA | ||
| Severity: | normal | CC: | lenb, rjw, rui.zhang, yakui.zhao |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.31 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 7216 | ||
| Attachments: |
lspci -vxx
dmesg before first hibernation dmesg after first hibernation, before first suspend dmesg after second hibernation and second suspend |
||
|
Description
Yves-Alexis Perez
2009-10-10 13:40:44 UTC
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. 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.
Thanks.
Please attach the output of acpidump, lspci -vxxx. thanks. Created attachment 23362 [details]
lspci -vxx
(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. |