[maverick] CPU frequency does not scale up unless all cores are in use

I have a very similar problem with my core i5 520 M (2 cores, 4 threads).
But, not as the previous case, my CPU never scales up. In fact I never manage to make it scale, it is always blocked to the lowest frequency.

For me, it may be a kernel problem. With the stock kernel provide by Maverick 10.10 Final :
Linux BlackBeast-T410 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:32:27 UTC 2010 x86_64 GNU/Linux

cpufreq-info shows me for all virtual cores :

analyzing CPU 3:
  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: 3
  maximum transition latency: 10.0 us.
  hardware limits: 1.20 GHz - 2.40 GHz
  available frequency steps: 2.40 GHz, 2.40 GHz, 2.27 GHz, 2.13 GHz, 2.00 GHz, 1.87 GHz, 1.73 GHz, 1.60 GHz, 1.47 GHz, 1.33 GHz, 1.20 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 1.20 GHz and 1.20 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.20 GHz.
  cpufreq stats: 2.40 GHz:0.00%, 2.40 GHz:0.00%, 2.27 GHz:0.00%, 2.13 GHz:0.00%, 2.00 GHz:0.00%, 1.87 GHz:0.00%, 1.73 GHz:0.00%, 1.60 GHz:0.00%, 1.47 GHz:0.00%, 1.33 GHz:0.00%, 1.20 GHz:100.00%

So, assuming the current policy and cpufreq stats, it's impossible to scale up over 1.20 GHz.
Even if I force with cpufreq-set.

By curiosity, I took the kernel sources from Lucid and I compiled it. (I never had this problem with Lucid, so let's try and see what happen.) :

Linux BlackBeast-T410 2.6.32-24-generic #8 SMP Tue Oct 12 02:09:23 CEST 2010 x86_64 GNU/Linux

cpufreq-info shows me for all virtual cores :

analyzing CPU 3:
  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: 3
  maximum transition latency: 10.0 us.
  hardware limits: 1.20 GHz - 2.40 GHz
  available frequency steps: 2.40 GHz, 2.40 GHz, 2.27 GHz, 2.13 GHz, 2.00 GHz, 1.87 GHz, 1.73 GHz, 1.60 GHz, 1.47 GHz, 1.33 GHz, 1.20 GHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance
  current policy: frequency should be within 1.20 GHz and 2.40 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.20 GHz.
  cpufreq stats: 2.40 GHz:3.26%, 2.40 GHz:0.02%, 2.27 GHz:0.05%, 2.13 GHz:0.05%, 2.00 GHz:0.03%, 1.87 GHz:0.02%, 1.73 GHz:0.03%, 1.60 GHz:0.01%, 1.47 GHz:0.03%, 1.33 GHz:0.03%, 1.20 GHz:96.48% (235)

It's far better than with the Maverick Kernel ! current policy and cpufreq stats return coherent values. The CPU scales up to 2.40 GHz with high CPU usage. So, cpufreq utils work, but not acpi-cpufreq kernel module ?!

There is also something weird... it can be reproduced with the 2 kernels :

when "/etc/init.d/cpufrequtils start" is invoked, I have got :

 * CPUFreq Utilities: Setting ondemand CPUFreq governor... * CPU0... ...

I have just tested with a fresh custom kernel 2.6.35.7 (from kernel.org).
The behavior is the same as the 2.6.35.4 Maverick Kernel.

I am getting the same behavior after upgrading to maverick with my Core 2 Duo T7200. Stuck at 1.00 GHz (minimum frequency) no mater what the stress level. Should be at 2.00 GHz.

The bug has been notified here too : https://bugzilla.kernel.org/show_bug.cgi?id=19702

On the reported bug from the link below, a patch has been provided. I have just tested it with a custom kernel 2.6.35.7, but unfortunately, it did not give any good result with my core i5 520 M.

cpufreq-info always return :

current policy: frequency should be within 1.20 GHz and 1.20 GHz.
The governor "ondemand" may decide which speed to use within this range.
current CPU frequency is 1.20 GHz.
cpufreq stats: 2.40 GHz:0.00%, 2.40 GHz:0.00%, 2.27 GHz:0.00%, 2.13 GHz:0.00%, 2.00 GHz:0.00%, 1.87 GHz:0.00%, 1.73 GHz:0.00%, 1.60 GHz:0.00%, 1.47 GHz:0.00%, 1.33 GHz:0.00%, 1.20 GHz:100.00%

After a bit more digging I discovered something interesting. When idling, the CPU has the full range of frequencies available to it, from min to max. But, when the load ramps up, the BIOS appears to step in and limit the frequency, then ACPI throttling steps in.

I used a simple script (attached) to discover this. Starting from an idle, cool CPU the BIOS maximum frequency is at max. A few seconds later, the limit starts to drop. A few seconds after bottoming out, ACPI throttling begins to increase. The full output I get is appended to the (in comments, at the bottom).

It is also interesting to note that the CPU fan is always at max, even when the CPU is idling.

Hi Michael,

If you could also please test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

Hey Jeremy,

I installed the latest upstream linux-image package and its two headers package. The linux image package is as follows:
linux-image-2.6.36-020636-generic_2.6.36-020636.201010210905_amd64.deb

I then ran the same test as before with this upstream kernel, and the frequency problem is still present.

I'm seeing this too with my AMD K325.

cpu info

When I ran two instances of burnK7 my cpu did not step up from 800 GHz, but last night when I was watching a video on iPlayer I noticed that it did start stepping up (top reported *over* 100% CPU usage). If anyone can explain how I can test this bug I would be happy to do so.

I had a similar problem on my Asus U43JC which runs on an Intel i5-450m (using Ubuntu 10.10). The BIOS would limit my frequence at 1.2GHz, no matter what cpufreq governor I was using, no matter if on the power cord or on the battery. To fix this, I added "processor.ignore_ppc=1" to the kernel boot parameters.

To see if you have the same problem, do a:

$ cat /sys/devices/system/cpu/cpu0/cpufreq/bios_limit

In my case, anything less than 2400000 means the workaround is necessary. To implement it, just add "processor.ignore_ppc=1" to the GRUB_CMDLINE_LINUX_DEFAULT paramenter in /etc/default/grub, and then run:

$ sudo update-grub

Reboot.

In my case, I solved this problem with BIOS configuration. In my BIOS I set "Performance" profile instead of "Power-Saving" for AC/DC and Battery Mode. Result : bios_limit returns now 2.40 GHz instead of 1.20GHz, and cpufreq can do his job. (Tested with 2.6.36 kernel too).

But it's not the only thing. My previous observation was made with my battery plugged
on my laptop, with AC/DC power. Another day, without battery, I was very
surprised when I saw that the bios_limit was still stuck to 1.20GHz (!). I think it's a BIOS related problem. But fortunately, "processor.ignore_ppc=1" boot parameter does perfectly the job. (Phew !!!)

I don't know if my issue is related here.
Ondemand and any scaling works fine for me when I run on AC power, but when I run on battery only, the cpu behaves strangely and very rarely scales up. Even if I load a flash game in my browser it stays at 800 mhz on the core running the object. Sometimes it scales up shortly, but don't know why.
More strange is it that if I set it to max (2 Ghz) it scales down both cores when running anything that uses cpu.

Somehow my system started behaving normally on battery after a boot into Windows 7. Any suggestions for what could be wrong?

look at the page http://www.thinkwiki.org/wiki/Problem_with_CPU_frequency_scaling. Ther's described solvation of problem with lenovo but it can be the same mechanism. My cpu ran constantly on lower speed and after making described solution now it's ok.

The requested information has been provided.

I have been experiencing something with very similar symptoms to this on a Dell Latitude E6410 laptop with Ubuntu 12.04. Looking in /sys/devices/system/cpu/cpu*/cpufreq showed that the CPU frequencies were always stuck at just under half what they could do, no matter the load. After finding this ticket I installed cpufrequtils, to get more readable output, with the immediate result that the CPU frequencies started behaving sensibly! I presume that init scripts which come with that package, including the one to load relevant CPU frequency-related kernel modules have something to do with it, but I am somewhat surprised, given the impressive effect that installing the package had, that it isn't installed by default. Does anyone else know something here that I don't?

Michael DePaulo, thank you for reporting this and helping make Ubuntu better. Maverick reached EOL on April 10, 2012.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We were wondering if this is still an issue in a supported release? If so, could you please test for this with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the kernel in the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested and remove the tag:
needs-upstream-testing

This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the text:
needs-upstream-testing

If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested.

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested.

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-unable-to-test-upstream
kernel-unable-to-test-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested.

Please let us know your results. Thank you for your understanding.

Helpful Bug Reporting Tips:
https://help.ubuntu.com/community/ReportingBugs