CPU Frequency scaling doesn't work and it's showing the wrong frequencies?

In Karmic, acpi_cpufreq is compiled into the kernel rather than being left as a module. Right?

When you say the CPUFreq applet is showing "the wrong frequencies," what do you mean?

I ask because I have a related problem: lscpu and cat proc/cpuinfo seem to show the wrong frequencies for my processor -- aT2500 @2.0 GHz.

CPU MHz is shown to be 1000MHz and CPU scaling, as shown by cpufreq-info (from the cpufrequtils package) is set to vary "between 1000MHz and 1000Mhz."

As in "either vote for Mobutul, or else ... vote for Mobutu."

I have never solved this problem after weeks of trying, using the SYS interface to cpufreq -- e.g., "echo 2000000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed" to try to reset the maximum. No dice.

Same with cpufreq-set -c 0 -u 2000000 and variations on that theme.

In my case, the correct governors were always loaded, and the correct four frequency steps were always detected. I am not sure, but it seems the incorrect information output by lscpu was affecting the scaling_set_speed or something like that. Not much debugging info available from dmesg.

Finally, I turned off SpeedStep in BIOS. Now, lsusb blurts out what appears to be the right info for my dual-core processor:

Architecture: i686
CPU(s): 2
Thread(s) per core: 1
Core(s) per socket: 2
CPU socket(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 14
Stepping: 8
CPU MHz: 1997.210
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 2048K

I would rather have speed scaling work, but for now, at least I can get work done on my machine until a fix is developed.

I keep responding to bug reports on this because I see a lot of laptop users reporting this problem (in many distros, which makes this a kernel bug rather than a distro bug), across various Ubuntu and other releases, but never an explanation.

Someone please compile the kernel with CPU_FREQ_DEBUG=y and dig into this!

At the risk of being a loathsome creature living under a bridge, I just hope if enough noise is made about the problem some Level 10 kernel mage will take pity on us meek end-users.

Hi, thanks for the reply. I'll try to provide as much information as I can though I should give plenty of forewarning that I'm fairly new to Linux in general and haven't yet had much time to come to grips with most of it yet.

"$ cat /proc/cpuinfo" ----- This yields:

"
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 14
model name : Genuine Intel(R) CPU T2400 @ 1.83GHz
stepping : 8
cpu MHz : 1828.851
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts pni monitor vmx est tm2 xtpr pdcm
bogomips : 3657.70
clflush size : 64
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 14
model name : Genuine Intel(R) CPU T2400 @ 1.83GHz
stepping : 8
cpu MHz : 1828.851
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts pni monitor vmx est tm2 xtpr pdcm
bogomips : 3657.80
clflush size : 64
power management:
"

Though frequency scaling reports a range from 125Mhz - 1Ghz for each core. Worth noting that earlier the above command was registering a CPU speed of only 1Ghz.

We could have a n00bosity contest, but I have learned stuff from poring over the forumson this problem.

Some users have reported luck with commands provided by sysfsutils and cpufrequtils. For example, with cpufreq-set you can try to set upper and lower limits, maximum frequency, and governor. With sysfsutils, you can get information from /the various entries sys/devices/system/cpu/*/cpufreq, using the cat command, or even try to set them manually with the echo value > command.

Also heavily discussed is the BIOS-ACPI interface. You know that acpi-cpufreq is compiled in now together with a lot of the drivers that used to be modules. For example, I THINK my processor might need the driver speedstep-smi or speedstep-ich, but I cannot do much about it.

What I have had SOME success with is editing grub (in my case, /etc/default/grub, for GRUB2, or else /boot/grub/menu.list for good old GRUB) and trying out various boot parameters.

At this moment, scaling is working fine on my machine. Boot parameters (from dmesg | grep boot)::

Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.33-020633rc4-generic root=UUID=1430ab7b-da45-46a3-8f27-d7a64f6bf08b ro pnpacpi=off irq=poll crashkernel=384M-2G:64M,2G-:128M ro debug xsplash

Yes, I am insanely running the mainline kernel from the PPA. This broke for me in 9.10, so I kept upgrading, hopnig for an easy fix. Not!

:I guess the pnpacpi=off parameter means that info on the CPU is read from the BIOS.

Running lscpu right after logging in correctly IDed my procesor, but now, 15-20 minutes into the session, it is giving the wrong CPU MHz figure again. Even so, cpufreq-info is correct so far:

cbrayton@macunaimachine:~$ sudo cpufreq-info
[sudo] password for cbrayton:
cpufrequtils 006: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to <email address hidden>, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 1000 MHz - 2.00 GHz
  available frequency steps: 2.00 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 1000 MHz and 2.00 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 2.00 GHz (asserted by call to hardware).
  cpufreq stats: 2.00 GHz:72.61%, 1.67 GHz:3.92%, 1.33 GHz:5.87%, 1000 MHz:17.59% (186)
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 10.0 us.
  hardware limits: 1000 MHz - 2.00 GHz
  available frequency steps: 2.00 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 1000 MHz and 2.00 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 2.00 GHz (asserted by call to hardware).
  cpufreq stats: 2.00 GHz:8.14%, 1.67 GHz:0.39%, 1.33 GHz:0.30%, 1000 MHz:91.17% (1834)

Hooray! This is what I want. And I can successfully use the CPU Freq Applet (gnome-applets) to change the governor back to the default ondemand.

Warning: I thought I had this licked earlier, using boot parameters, but it returned to haunt me on subsequent boots.

Hope this helps. What I think I really need is (1) for drivers to be modularized, so I can try, say, speedstep-ich instead of acpi-cpufreq, and (2) for developmet kernels to be compiled with CPU_FREQ_DEBUB=y. I would do it myself, but I am not confident about my kernel-compiling knowledge (plus it takes hours and hours). But I did read one exchange between kernel gurus about the output of cpufreq-debugging that kind of helped me ....

Hope this puts you on the right path somehow. Between wrong information from hardware monitors and what the kernel is actually doing to your CPU, it gets crazy.:

Hi there,

Not much help that I can provide right now. Just to let you know you're not alone, I have the exact same problem in 9.10 as Brayton, just noticed yesterday.

I already went through all the "imediate" stuff like echoing a new upper value through sysfs, no luck. Tonight I'll try the boot parameters, I also found a post by a guy with the same problem who apparently solved it by adding:

acpi=noirq
pnpacpi=off

Anyway, if it doesn't work I'll recompile the kernel with cpufreq features as modules so at least I can unload them, and set CPU_FREQ_DEBUB=y so I get more info.
I'm not feeling too confident though, I know I have a buggy bios and no way to update it (stay away from LG laptops).

By the way, Brayton, for a poetry major, you know your way around this stuff. :)

LTX, thx! Currently, for me, Ubuntu boots perfectly first thing in the morning, with freq scaling rocking and rolling and everything peachy. 10 minutes later, it breaks, and then various bad things happen randomly. At best, I can get it going with freq scaling apparently okay, but the CPU still maxed out while running the most basic apps, such as browser and e-mail, which ordinarily would not take up more than 15%-30% of CPU capacity.

Funny thing is, I booted today from a Debian Lenny Live CD and boom! Ran perfectly for hours and hours with the exact same driver (acpi-cpufreq).

 I am sitting here comparing the dmesg | grep CPU from Ubuntu and Lenny and trying to get a clue from that. I sometimes think that cpufrequtils themselves may be part of the problem. (I have also tried the sysutils "echo [freq] to /.../.../current_freq" method you mention.)

You are so right: cpufreq.debugging=y should be compiled and the results passed around to sufferers from this problem. Could make a good wiki page under User Documentation.

That suggestion about pnpacpi=off probably came from my own stupid blog post, which is very high in the Google results for intuitive googles on this issue. (Stupid blogs have far too much Google clout.)

(I may have to start transitioning to another distro. Am installing Lenny to a big bootable USB storage brick to see how that works.)

Actually I'm not sure if it is the cpufreq driver itself or the bios acpi access routines, which may be different in Lenny, or even some other stuff interfering. If I do:

cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state

I can see that at some point in time (probably during early boot) the damned thing was in other states other than the lowest one, meaning that scaling_max_freq actually had a DIFFERENT value... But by the time I get a terminal running (in runlevel 5, I have to try booting to runlevel 3 yet) the thing is stuck at 800MHz and won't budge.

When I bought the laptop I went through all the "geek with a new toy" steps and haked OSX into the thing, that's how I know that my bios acpi is buggy, spent weeks trying (and failing) to boot and the final solution was overriding the DSDT table AND using an older acpi driver. But I never had problems with linux up to now.

I also may end up changing distro. I love ubuntu for it's simplicity, but when we reach a point where you have to recompile the kernel to have a shot to just use your hardware as it was meant to be, it's not really that simple is it...

Cheers

Hi again,

I managed to solve this for my case, hopefully it will be of help to someone else. Here it goes, I'll explain the tests I did first so anyone trying to reproduce it may find it easier.

First I compiled a new kernel (2.6.33-rc7 or something, the latest from the main git tree), setting CPU_FREQ_DEBUB=y, and compiling all cpufreq related drivers as modules to be able to load/unload them. Long story short: no deal, the problem still existed, and no error messages whatsoever were given.

What got me on the right track was that booting with acpi=noirq worked for me, the frequency scalling worked, but I lost some Fn key combinations. So I did:

cat /proc/interrupts

and saw that I had IRQ 9 assigned to acpi, but no interrupts had been detected. I booted without the flag, and frequency scaling stopped working, I still had IRQ 9 assigned to ACPI, but this time lots of interrupts had been triggered. This indicated to me that and interrupt from the ACPI was screwing up the frequency scaling, and that was why acpi=noirq solved it (by blocking said interrupt). But of course that booting like that may cause a lot of other issues (e.g. Brayton's erratic behavor, well, not Brayton's, Brayton's computer :)).

And by pure luck (really) I got it. My laptop was getting a bit hot, I have the bios setting the fan speed or whatever to "silent mode", so I hit the Fn combination that restores the fan speed to normal. And voila, suddenly the frequency scaling started working.

Put it all together and I had the answer. In my case, selecting the fan speed to silent mode caused the bios to trigger an interrupt and update the cpuinfo max speed to the lowest possible step (in the bios yet). When that happened, linux updated the cpufreq max limits, and would not let me change it to a higher value because in fact the bios reported that the CPU did not support it. The acpi_cpufreq driver was in fact working correctly.

I suppose that this is a "safeguard" in my laptop bios ("you want it silent, I'll make sure it does not catch fire"), but it is not documented anywhere. This may not even apply to anyone else, but then again:

If your frequency scaling is not working, and acpi=noirq gets it on, go to your bios and turn off any APM optimizations or any "smart" controlling of cpu temperature, or fan speed or whatever. Your bios may very well be trying to control something by providing wrong values to your operating system.

Let me know if this helped.

Cheers,
LTX