Kernel Bug Tracker – Bug 8581
acpi-cpufreq gets very confused on suspend to ram
Last modified: 2011-01-18 07:39:35 UTC
Most recent kernel where this bug did *NOT* occur: Only switched to
Distribution: Ubuntu 06.10
Hardware Environment: Thinkpad X40
After startup acpi-cpufreq works as expected either running the
ondemand or the conservative governor. When using the conservative
governor, the cpu frequency stays at full speed after a suspend to ram
/ resume cycle. Switching to performance and back to conservative
seems to restore the usual behaviour.
Even more strange are the symptoms when running the ondemand governor.
A s2ram / resume cycle automatically switches to conservative, for
some reason, and I made a rather thorough search in /etc to ensure
that this is not due to some acpi, laptop-mode or similar script. At
least, cpu frequency drops to the lowest frequency but after a second
s2ram/resume cycle there it shows the same behaviour as described
above, i.e., frequency stays at full speed.
Just for the record, speedstep-centrino which I've been using until
now still works as expected. In my configuration its switching the
cpufreq driver that triggers the problem. And there is another
difference although it might be known and considered a limitation
rather than a bug: Whereas the speedstep-centrino module apparently
can be unloaded during normal operation, the same does not apply to
acpi-cpufreq as the module is claimed to be in use even after
switching to the performance governor and setting everything to the
Does the issue remain in the newest kernels (eg. 2.6.23-rc2)?
There are some important fixes related to ACPI/suspend in the current Linus' tree (2.6.23-rc7-git4 as of today). Can you test it please?
Please test the 2.6.23-rc9 kernel or 2.6.23 final when it's out.
[I'm going to close this entry if there's no response in two weeks from now.]
[Sorry for the delay.]
There still are some issues. On 2.6.22 and 2.6.23-rc9-git6 I see this
echo mem > /sys/power/state
and resuming afterwards, /proc/cpuinfo reports maximum frequency. It
stays that way during normal operation until a more demanding process
is being launched. For instance when starting to compile the kernel,
the cpu is switched to the but lowest frequency (after some threshold,
of course) and behaves as expected from now on. So, there are two odd
1. cpu stays at highest frequency after a suspend/resume cycle;
2. once there is enough load to trigger a frequency switching event,
the switching algorithm behaves as if the cpu had been at the
lowest frequency all the time, i.e., it steps through all the
possible frequencies starting at the low end of the scale.
Well, I'm not familiar with the cpufreq code. I'll try to have a look at it, though (I can't promise that will be soon).
Created attachment 13218 [details]
Applies to 126.96.36.199
Please apply the attached patch. Since it is a small one, I think it
should go to the stable team as well.
there's some whitespace damage in this patch (spaces instead of tabs).
Asides from that though, it looks like the right thing to do.
Can you fix that up, and bounce a copy to firstname.lastname@example.org please?
Fixed in 2.6.24-rc3.
*** Bug 9181 has been marked as a duplicate of this bug. ***