en en en en en en ceb yue en en en en mk en hbs_lat eu en en en en es it en en en tr en en en en en en ru en en ro en en en ceb en en pt es en en en en en en en en en en en en ca en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en ceb yue en en en en mk en hbs_lat
Comment 1 Elias Oltmanns 2007-06-04 05:41:38 UTC
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
Comment 2 Rafael J. Wysocki 2007-08-08 10:11:25 UTC
Does the issue remain in the newest kernels (eg. 2.6.23-rc2)?
Comment 3 Rafael J. Wysocki 2007-09-23 05:26:31 UTC
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?
Comment 4 Rafael J. Wysocki 2007-10-06 08:38:36 UTC
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.]
Comment 5 Elias Oltmanns 2007-10-08 06:47:58 UTC
[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.
Comment 6 Rafael J. Wysocki 2007-10-12 12:48:37 UTC
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).
Comment 7 Elias Oltmanns 2007-10-21 06:13:07 UTC
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.
Comment 8 Dave Jones 2007-10-21 17:24:22 UTC
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.