Kernel Bug Tracker – Bug 10053
System dead after resuming from S3, but not when docked - Dell Precision M20/ Latitude D610
Last modified: 2008-06-11 02:11:38 UTC
Latest working kernel version: 2.6.23
Earliest failing kernel version: 2.6.24
Hardware Environment: Dell Precision M20 (almost the same as Dell Latitude D610), Pentium M 2.13, Sonoma i915, ati radeon x300 (using radeon driver)
Problem Description: System suspends properly after echo "mem" > /sys/power/state. After pressing the power button again, hardware wakes up but the system is not responding and neither the kernel magic keys work nor the LCD backlight. Dead. However if I suspend while being docked (dock module loaded) and then resume (still docked) it surprisingly will resume just fine. Tried many times and it just works that way. Please note that suspending when undocked and resuming when undocked and the vice versa will not work.
2.6.23 worked without any problems, in all the situations described above.
Steps to reproduce:
*Please note that suspending when
docked and resuming when undocked and the vice versa will not work.
I also forgot to mention that nothing new is written to syslog after resuming, there is completely no trace of system activity.
please attach that syslog
and the output from acpidump
Will you please set "CONFIG_PM_TRACE , CONFIG_PM_TRACE_RTC "in kernel configuration and do the following tests? (The system should be booted without dock).
a. boot the system with the option of "initcall_debug acpi_sleep=s3_bios"
a. echo 1 > /sys/power/pm_trace
b. echo mem > /sys/power/state
c. press the power button and see whether the system can be resumed. If the system can't be resumed, please restart the system with the option of "initcall_debug" and attach the output of dmesg.
Just to let you know: I will do the test next week.
OK, I did the testing today. acpi_sleep=s3_bios causes immediate reboot here after pressing the power button to resume the system. It always used to be like that AFIR (did some testing some time ago). So I tried without this option and got some results. However dmesg output lacks initcall messages that I saw on the screen while booting, I am not sure if that's the way it's supposed to be.
Created attachment 14931 [details]
dmesg output taken after booting up
- run with initcall_debug option
- echo 1 > /sys/power/pm_trace
- echo mem > /sys/power/state
- pressed power button, system hanged as described earlier
- rebooted with initcall_debug option
- dmesg >> dmesg_without_s3_bios
Created attachment 14932 [details]
Thanks for the info. But the output in comment #7 is not completed.
Will you please upload the full dmesg output ?
Did you read my Comment #6? For some reason there are no initcall messages included in dmesg and I don't know why is that.
Maybe the reason about no initcall messages is that the kernel log buffer is very small.
Will you please increase the CONFIG_LOG_BUF_SHIFT in kernel configuration and attach the full dmesg? (For example: 18/19).
If boot option of "acpi_sleep=s3bios" is added, the system will immediately be rebooted after the power button is pressed. Please not add this option.
Will you please do the test again as in comment #7?
Created attachment 15037 [details]
OK, that helped. Here's the proper dmesg output. I obviously didn't add acpi_sleep=s3bios option.
Hi. I tried s2ram yesterday and... resuming works fine now. This is quite surprising, I didn't expect that. According to whitelist entry for my laptop model, all the s2ram does is saving and restoring vbe state.
Is there still a failure here to debug, or is everything working?
Len, I don't understand your question? Debugging is fine already, I attached the proper output. Not everything is working with S3 however, because with 2.6.23 resuming worked fine without any quirks and now I need to use s2ram, so there is some regression in this area definetely.
Hmm, I think the question is:
Does the laptop still hang when resume? Or it's just a black screen issue?
No, with s2ram tool everything works fine now.
In my case s2ram is not a solution. I have got the problem since i upgraded to ubuntu hardy which is using kernel 2.6.24. On the same system i have tried with 2.6.22 and it works, so i must be the kernel.
Does these options mean i have to rebuild the kernel: CONFIG_PM_TRACE , CONFIG_PM_TRACE_RTC
Created attachment 15711 [details]
Mark, forst please make sure it's the same problem as Dawid described in this bug report, i.e. the same symptom on the same/similar hardware.
If no, please open another bug report. :)
Sounds like a black screen issue. Rui, should we close this one or move it to graphic catalog?
This seems to be a black screen issue.
And this should be fixed in the latest kernel release, say 2.6.25, if it uses an Intel integrated graphics card.
Please give it a try, please re-open it if you still have any questions.