Most recent kernel where this bug did *NOT* occur: Only switched to acpi-cpufreq now. Distribution: Ubuntu 06.10 Hardware Environment: Thinkpad X40 Software Environment: Problem Description: 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 startup defaults. Regards, Elias
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 behaviour: Driver: acpi-cpufreq Governor: conservative When issuing 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 things: 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 2.6.23.1 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 cpufreq@www.linux.org.uk please? Thanks.
Fixed in 2.6.24-rc3.
*** Bug 9181 has been marked as a duplicate of this bug. ***