On Fri 30. Dec - 23:20:19, Alistair wrote:
Hello
I have two Centrino laptops that exhibit similar problems with 10.0
If I start the machine on power, and then query the cpu, I get this...
alistair@juno:~> cpufreq-info cpufrequtils 0.3: cpufreq-info (C) Dominik Brodowski 2004 Report errors and bugs to linux@brodo.de, please. analyzing CPU 0: driver: centrino CPUs which need to switch frequency at the same time: 0 hardware limits: 600 MHz - 1.10 GHz available frequency steps: 1.10 GHz, 800 MHz, 600 MHz available cpufreq governors: ondemand, userspace, powersave, performance current policy: frequency should be within 600 MHz and 1.10 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 600 MHz.
...which is correct.
Unplugging from AC to battery, gives me:
alistair@juno:~> cpufreq-infopo [snip] current policy: frequency should be within 600 MHz and 600 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 600 MHz.
Which is also correct for power saving. However, I plug the machine back in again to AC, it sticks with the restricted speed range policy, and does not revert to the full range shown first. I have to do something like...
juno:/home/alistair # cpufreq-set -u 1.1GHz
... to sort this.
Did you check whether the frequency really staid at 600 MHz after replugging and loading the cpu? Maybe only the information shown is wrong...
It is similar with my other laptop, except replace 1.1GHz with 1.5GHz.
This seems wrong to me. Is it a known problem or a user failure? Otherwise, I will file a bug.
On SUSE systems, by default, the powersave daemon cares about cpu frequency scaling. Therefore, cpufrequtils can only be used to get information and not for setting policies as long as the powersave daemon is running. It is highly adviced to use the powersave daemon, respectively the command 'powersave' or one of the clients like kpowersave to control cpu frequency scaling on SUSE systems. The problem mentioned by you seems to me like a problem within the cpufrequtils package. The right place for submitting this information would be the cpufreq mailing list [1]. Regards, Holger [1] http://lists.linux.org.uk/mailman/listinfo/cpufreq