On my Dell Precision M65 the power consumption after a clean boot is much higher than after a suspend to ram cycle. After a clean boot it uses aproximately 1900mA and after a suspend to ram cycle it uses aproximately 1400mA. I cannot find any hints in dmesg.
The problem seems to be the same as described in http://bugzilla.kernel.org/show_bug.cgi?id=11122 for HP Laptops.
I tried this with kernel versions from 2.6.29 to 2.6.32. The missbehaviour was always reproducible. Thus it was reintroduced in 2.6.28 or 2.6.29.
I'll reassign this to ACPI.
please attach the output from powertop -d for the high-power
and low-power cases.
Created attachment 24275 [details]
Hight Power State (before suspend)
Created attachment 24276 [details]
Low Power State (after suspend)
Created attachment 24277 [details]
dmesg output (boot, then suspend, then resume)
The outputs I just posted are from latest zen-kernel, but the same problem is also present with vanilla sources (tried 2.6.32 without any patches).
please set CONFIG_PM_DEBUG, and run this test:
"echo core > /sys/power/pm_test"
"echo mem > /sys/power/state"
wait about 10s
does the power consumption drop after the system coming back?
I tried to do so, but the system does not come back when I echoed core > pm_test before. The screen stays black. When not echoing core > pm_test the supend cycle works and the system of course consumes less power afterwards. Afterwards the test cycle with echo core > pm_test works and the system also consumes less power.
I don´t think, that this information is of any use...
what do you get after running "echo core > /sys/power/pm_test" and "echo mem > /sys/power/state"?
you said the screen is black, is the screen still black after 20 seconds?
does the system hangs? say, ping this laptop and see if there is response.
do you have to reset to get the system back to work?
The screen is still black after 20 seconds. The Laptop is not pingable. Sometimes I noticed blinking keyboard LEDs. I have to reset the laptop to bring is back to work.
please try to echo processors/platform/devices/freezer instead of "core" to /sys/power/pm_test, and see with which value the S3 test can resume successfully.
Sorry, I was busy the last weeks. I tried to echo processors/platform/devices/freezer into pm_test. I used a fresh boot every time and was on battery power. Platform, devices and freezer worked. Core and Processors crashed as reported before. The power usage went down after platform and devices. The power usage stayed high after core and processors. One strange thing I noticed was that running one cycle with devices after the freezer cycle (this time without reboot) the system also crashed.
Hah, an interesting bug.
have you ever seen a system that works well in S3, but fails in the pm_test?
No, I haven't, but I bet this the bug discussed here:
(In reply to comment #15)
> No, I haven't, but I bet this the bug discussed here:
I'm afraid this won't help because the patch above is a fix for hibernation.
does the problem still exist in the latest upstream kernel?
The problem still persists in 188.8.131.52-zen, which was the latest one I tried.
The problem is still there in 184.108.40.206.
It's great that kernel bugzilla is back.
can you please verify if the problem still exists in the latest upstream
The problem is still there with 3.0 kernel, which is the last one I tried. I will write again when I have built a newer kernel.
The problem is still there with 3.2 kernel.
(In reply to comment #13)
> Sorry, I was busy the last weeks. I tried to echo
> processors/platform/devices/freezer into pm_test. I used a fresh boot every
> time and was on battery power. Platform, devices and freezer worked. Core
> Processors crashed as reported before. The power usage went down after
> and devices.
You mean the system consumes less power after resuming from "echo device > /sys/power/pm_test && echo mem > /sys/power/state", but not for "freezer", right?
can you attach the output of the latest powertop tool both before and after pm_test?
I think it is okay to close this bug report as there is no response from the bug reporter for one year.
But please feel free to reopen it if the problem still exists in the latest upstream kernel.