The ondemand CPU frequency governor has stopped working for me a few days ago when my laptop runs on battery power, even though cpupower reports that everything is ok:
# cpupower frequency-info analyzing CPU 0: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 10.0 us. hardware limits: 800 MHz - 2.70 GHz available frequency steps: 2.70 GHz, 2.70 GHz, 2.40 GHz, 2.20 GHz, 2.00 GHz, 1.80 GHz, 1.60 GHz, 1.40 GHz, 1.20 GHz, 1000 MHz, 800 MHz available cpufreq governors: ondemand, performance current policy: frequency should be within 800 MHz and 2.70 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 800 MHz (asserted by call to hardware). cpufreq stats: 2.70 GHz:0.00%, 2.70 GHz:0.00%, 2.40 GHz:0.00%, 2.20 GHz:0.00%, 2.00 GHz:0.00%, 1.80 GHz:0.00%, 1.60 GHz:0.00%, 1.40 GHz:0.00%, 1.20 GHz:0.00%, 1000 MHz:0.00%, 800 MHz:100.00% (24) boost state support: Supported: yes Active: yes 3200 MHz max turbo 4 active cores 3200 MHz max turbo 3 active cores 3200 MHz max turbo 2 active cores 3400 MHz max turbo 1 active cores
The frequency stays at the minimum of 800 MHz even when I have 4 parallel busy loops maxing out the CPU. On AC power, the governor works as expected. Even on battery power, I can set the governor to "performance" and the frequency goes up to 2.7 GHz as expected. The "conservative" governor works as well.
I'm running a 64-bit systemd installation on a Dell Latitude E6420. The processor is a dual core i7-2620M with hyperthreading enabled. Laptop-mode is enabled, but configured to leave the CPU frequency alone (CONTROL_CPU_FREQUENCY=0). Stopping laptop-mode does not change anything.
I have also tried loading cpupower at startup, adding processor.ignore_ppc=1 to the kernel command line, manually setting the ondemand governor while the system is running, and probably a dozen other things, all to no avail.
I'm not sure exactly when the problem started. A lot of things have happened since it last worked: two kernel updates, cpupower replacing cpufreq-utils, me switching the system to systemd. So downgrading packages to find the source of the error seems pretty daunting.
For the record, this problem persisted after the upgrade to kernel 3.6. I "fixed" it by tweaking the performance governor, setting the up_threshold to 90 instead of the default 95. Values as high as 75 cause at least one core to be pegged at the maximum frequency, btw, which also doesn't seem right.