Hi-
I am using the current 2.6.27.8 kernel on Fedora 10:
http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.27.8.tar.bz2
I am experiencing resets in cpu scaling policy using cpufreq and the
e_powersaver driver on my Cloudbook which uses a VIA C7-M CPU.
Initially, I configure it to use the ondemand governor with the
frequency range 600MHz-1200MHz, as shown here:
cpufrequtils 005: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to cpufreq@xxxxxxxxxxxxxxx, please.
analyzing CPU 0:
driver: e_powersaver
CPUs which need to switch frequency at the same time: 0
hardware limits: 400 MHz - 1.20 GHz
available frequency steps: 400 MHz, 500 MHz, 600 MHz, 700 MHz, 800
MHz, 900 MHz, 1000 MHz, 1.10 GHz, 1.20 GHz
available cpufreq governors: ondemand, userspace, performance
current policy: frequency should be within 600 MHz and 1.20 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 700 MHz (asserted by call to hardware).
However, when the system is under load, it soon resets to 480-500MHz range:
cpufrequtils 005: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to cpufreq@xxxxxxxxxxxxxxx, please.
analyzing CPU 0:
driver: e_powersaver
CPUs which need to switch frequency at the same time: 0
hardware limits: 400 MHz - 1.20 GHz
available frequency steps: 400 MHz, 500 MHz, 600 MHz, 700 MHz, 800
MHz, 900 MHz, 1000 MHz, 1.10 GHz, 1.20 GHz
available cpufreq governors: ondemand, userspace, performance
current policy: frequency should be within 480 MHz and 500 MHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 500 MHz (asserted by call to hardware).
Here is the portion of dmesg when the transition takes place (with
kernel parameter cpufreq.debug=7):
freq-table: request for target 719978 kHz (relation: 1) for cpu 0
freq-table: target is 3 (699979 kHz, 1799)
cpufreq-core: notification 0 of frequency transition to 699979 kHz
cpufreq-core: notification 1 of frequency transition to 699979 kHz
cpufreq-core: setting new policy for CPU 0: 600005 - 1199964 kHz
freq-table: request for verification of policy (600005 - 1199964 kHz)
for cpu 0
freq-table: verification lead to (600005 - 1199964 kHz) for cpu 0
freq-table: request for verification of policy (479985 - 479985 kHz) for
cpu 0
freq-table: verification lead to (479985 - 499985 kHz) for cpu 0
cpufreq-core: new min and max freqs are 479985 - 499985 kHz
cpufreq-core: governor: change or update limits
cpufreq-core: __cpufreq_governor for CPU 0, event 3
cpufreq-core: target for CPU 0: 499985 kHz, relation 1
freq-table: request for target 499985 kHz (relation: 1) for cpu 0
freq-table: target is 1 (499985 kHz, 1286)
Unfortunately, there have been reports of other cloudbook users losing
keyboard and touchpad input after the cpu frequency scales to 400MHz, so
we try to set the policy to never allow cpufreq to scale that low. When
the reset occurs, apparently it does enter that condition soon after.
I recently sent a bugreport to RedHat but it might take some time. I was
advised to ask here and in the least I might maintain my own kernel with
a patch until it's committed upstream.
Thanks for your help-
Amin
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
