kernel can't scale cpu frequency

Please attach (do not paste into comments) the output of dmesg and lsmod.

lsmod of Pentium ULV

dmesg of Pentium ULV

I don't see any output in dmesg regarding your CPU scaler module actually working.

Try doing:

sudo /etc/init.d/powernowd stop
sudo /etc/init.d/powernowd start

Send the output of those two commands.

Also, for reference, you do not need to compress the files posted to the bug report. Further, you should never tar a single file. If it needed to be compressed you could simply compress the single file rather than tar/compress.

$ sudo /etc/init.d/powernowd stop
 * Stopping powernowd: [ ok ]
$ sudo /etc/init.d/powernowd start
 * Starting powernowd... [ ok ]

By the way the kernel governors like ondemand doesn't work too.
I have compressed the file with Krusader since I don't wanted to read the man page and I think it is no real problem with tar. If I open this compressed file in Krusader or Konqueror it is directly opened in Kate (texteditor) so I see no real problem.
Why should I read a man page if it works this way but I don't compress it in future if you want.

With new kernel version 21 scaling doesn't work with any kernel (386 and 686).

I have the same problem on my HP nx9030 with a today fresh Dapper installation.

In this tar I group many output files while runing i686 and i386 kernels.

I have an Inspiron 8600 with a 1.3Ghz Pentium M which also does not scale the CPU frequency using the i686 kernal. The i386 kernal, though, works great and scales the freq dynamically. Under the i686 kernal, my freq remained at 600Mhz no matter what load causing severe slowdowns when rendering large webpages, installing software, running software, etc. Also, this bug is not power state dependant (meaning that whether plugged in or not, it does not scale the CPU). This problem also appeared in the SuSE 10.1 Betas, but I did not isolate the problem until using Dapper.

I'm seeing this with a Dell D600 (1.6 GHz Pentium M), using both the 386 and 686 kernels in Dapper final. dmesg is similar to others on this page. It should be noted that when this happens, the frequency sticks at the _lowest_ value. Oddly, scaling_max_freq shows 600000, the same as scaling_min_freq, while scaling_available_frequencies shows "1600000 1600000 1600000 1400000 1200000 1000000 800000 600000".

Has there been any progress on this? It is making Dapper rather unusable for me.

No need to bump severity...

The severity was probably bumped because:

* The bug now affects both the 386 and 686 kernels. Thus there is no workaround listed in the bug.
* Instead of having the frequency stuck at the *highest* value, the frequency is stuck at the *lowest* value on affected machines. In my case that means I am always running at 600MHz instead of 1.6GHz, which causes a very noticeable performance hit.

I've been working on trying to fix this, and have had some success in tracking down the problem. The problem occurs in the verification steps of __cpufreq_set_policy in cpufreq.c. If one comments out that (from after the memcpy to before the data->min = policy->min), cpufreq works fine.

Something seems to be going wrong with the verification step, but the debugging information doesn't appear to offer any specifics as to what step is going wrong. When the problem is there, I get the following output:

cpufreq-core: setting new policy for CPU 0: 600000 - 1600000 kHz
freq-table: request for verification of policy (600000 - 1600000 kHz) for cpu 0
freq-table: verification lead to (600000 - 1600000 kHz) for cpu 0
freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
cpufreq-core: new min and max freqs are 600000 - 600000 kHz

I'll get more on this later.

I've further narrowed this down to the cpufreq_verify_within_limits call inside acpi_processor_ppc_notifier in acpi/processor_perflib.c. I'm not quite sure why the maximum value gets set to the minimum value, but my guess is that for some reason, ppc is getting set to the lowest frequency state instead of the highest frequency state. I've stuffed some printk's in the code and will try to see if this is the problem the next time I reboot.

Yesterday with the update to 2.6.15-25, i compiled a new kernel with LinuxPHC-patch to ajust the voltages, processor family was 'Pentium M', and now scaling works fine. (patch from http://linux-phc.sourceforge.net/).

the default 686 kernel image still has the scaling bug, it does not change cpu speed, but the bogomips changed... only a bug in the /proc/cpuinfo-view?

Constantine: This patch from the 2.6.17 source tree fixes a bug that look like yours. I don't know if it will work on 2.6.15, but it might give you some idea about where to look.

Thanks for the patch. Probably be a couple of weeks before the next kernel gets uploaded, but this patch will be in there.

Here is the same patch with one line modified to apply to 2.6.15-25.

Constantine: Did you test if the patch fix your problem?

The patch applies cleanly with the changes, but won't compile, since mutex_lock and mutex_unlock aren't defined. After some cursory research, it appears that the functions are called down and up in 2.6.15. Is this correct? I am trying to compile the kernel with the names changed to up and down now.

Yes it should be up() and down() for 2.6.15.

Unfortunately, it seems that the patch does not fix the problem. I compiled 2.6.15-25.43 with the patch added, but with the same configuration, and it did not resolve the problem. I also tried the using the 2.6.17-2 from Edgy, and that also did not resolve the problem, so I am guessing that the patch doesn't fix the problem.

I'm using "linux-image-2.6.15-25-386" and it works fine in my Pentium-M (686 kernel goes very bad).
¿Why don't distribute a "linux-image-pentium-m"? I think that P-M is very extended in laptops and it could help.

I have also noted similar problem with 686 - it does not scale CPU on HP nw8240 (Pentium-M 2.13GHz). I have installed 386 kernel yesterday and CPU frequency scaling works (and system does not heat-up as it did before).

I am not sure if this bug was introduced with dapper-updates or if it was in 2.6.15.23, as I have used only 386 kernels during Dapper testing (and scaling worked all the time), while I got 686 just after Dapper release when I did clean install (but then also got updated kernel very soon after).

On Mon, 2006-06-26 at 10:38 +0000, Luka Renko wrote:
> I have also noted similar problem with 686 - it does not scale CPU on HP
> nw8240 (Pentium-M 2.13GHz). I have installed 386 kernel yesterday and
> CPU frequency scaling works (and system does not heat-up as it did
> before).
>
> I am not sure if this bug was introduced with dapper-updates or if it
> was in 2.6.15.23, as I have used only 386 kernels during Dapper testing
> (and scaling worked all the time), while I got 686 just after Dapper
> release when I did clean install (but then also got updated kernel very
> soon after).

To be honest, most ppl don't need the 686 kernel. 386 kernel should work
fine (if not better) in most cases.

My problem was that this was happening with all kernels that I tried (386, 686, etc), and fixing it required hackish modification of the _PPC frequency limiting code, to stop it from incorrectly limiting. It appears that this bug is now gone as of 2.6.17-2 in Edgy, but I can't say for sure. The description in the patch for 2.6.17 is useful, reading it carefully makes it seem to me like the bug didn't manifest itself in Ubuntu because of a change in the kernel, but instead because of a change in something like init script timing, and also that the problem can appear somewhat randomly.

As far as I know, the bug is not fixed for Dapper however, and my attempt to backport the 2.6.17-rc2 patch didn't seem to work. I might try it again in a few days.

I have a possible workaround for this problem.

I still experienced the problem with the latest Ubuntu kernel (as of 20060724). In looking around I found this solution:
http://www.vmware.com/community/thread.jspa?messageID=321981&#321981

Basically, the performance problems stem from ACPI bugs that set the kernel into the wrong "cstate". So, I did this:
echo 1 > /sys/module/processor/parameters/max_cstate

My performance problems were then solved (at least until a reboot).

Hope this helps until a official fix comes out.

Ken, could you check to see if this happens with the 2.6.17 kernel in Edgy? I no longer have the problem now that I am using Edgy, and there is reason to believe that the issue was resolved by some changes upstream.

here's a "me too"...

ken, i tried your workaround but no luck :(

running 2.6.15-26-686 on a D600 fwiw...

Hello,

Well, my system is configured for Dapper. I'm afraid changing my apt sources to Edgy will break a lot.

So, I manually downloaded "linux-image-2.6.17-5-386_2.6.17-5.16_i386.deb" from packages.ubuntu.com. I tried to install it, but it complained I needed module-init-tools => 3.2.2-3ubuntu2.

I went back to packages.ubuntu.com, and the only Edgy version there was "module-init-tools_3.2.2-1ubuntu7_i386.deb". I installed it anyway.

I then installed the kernel, my dpkg complained about module-init-tools, but the new kernel is installed, albeit with no initrd or /lib/modules/.

I downloaded and installed "linux-source-2.6.17_2.6.17-5.16_all.deb". Copied config-2.6.17-5-386 to /usr/src/linux/.config. Ran "make" and "make modules_install", then tried to use yaird to create an initrd. Unfortunately, it it fails with "can't open kernel config file" even though the file is there and readable.

I'm not sure if all my installing, uninstalling, and reinstalling kernels messed something up.

Thanks,
Ken Gallo

I can confirm that this is fixed in Edgy 686 kernel. It would still be nice if fixed kernel would be released for dapper-updates though.

Contrary to the experience of Luka Renko, frequency scaling still doesn't work in the current Edgy kernel (2.6.17-7.20 generic). The odd thing however is that it does work in 2.6.17-7.20 386.

I have a Pentium M 2.0 Ghz.

I can confirm twhat mvandeg is saying. Frequency scaling does not work in Edgy Kernel 2.6.17-7.20 generic.

When I try to manually scale the frequency /proc/cpu still reports the same CPU speed. I have a dv2000t with an Intel Core 2 Duo (2.0ghz).

No such thing as 2.6.17 in dapper.

Please test 2.6.17-8.22, which should be in the archive now.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fjodor, the issue that you are having is not related to this bug. Please
file a new bug report about it if you can't find a relevant one.

That said, I think you need to ask on the forums or the mailing list,
since it doesn't appear you are experiencing a bug. Throttling is not
the same as scaling. Your computer most likely does not support Intel's
Speedstep, and needs some other module to be loaded.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFFDu4aejd/sU2TVARAnhvAJoDHbdMmYa2TQb5AyuwMps+iq5e5wCfTjtj
RT+0kyhbUfDbuCtLzjd1PvY=
=3+D9
-----END PGP SIGNATURE-----

I understand that you are fishing for resolution by acpi updates, but I would like to point out that my /proc/acpi/processor/CPU0/throttling lists

state count: 8
active state: T0
states:
   *T0: 00%
    T1: 12%
    T2: 25%
    T3: 37%
    T4: 50%
    T5: 62%
    T6: 75%
    T7: 87%

But still:

sune@tommelise:~$ sudo /etc/init.d/powernowd restart
Password:
 * Stopping powernowd: [ ok ]
 * Starting powernowd... /etc/init.d/powernowd: line 83: /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor: No such file or directory
 * CPU frequency scaling not supported
                                                                         [ ok ]
sune@tommelise:~$

And

sune@tommelise:~$ sudo modprobe speedstep-centrino
FATAL: Error inserting speedstep_centrino (/lib/modules/2.6.17.11-ubuntu1-pentium4m-7/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.ko): No such devicesune@tommelise:~$

/Fjodor

Sorry, didn't see the "Don't paste into comments". -5 karma points to me :-(

Can confirm this bug for my Thinkpad R60 dual core.
None of the workarrounds here can fix this annoying problem :(
Even with an edgy daily build both core doesnt scale.

i had the

 * CPU frequency scaling not supported

and

error inserting speedstep-centrino issues on my HP NC8430

Bios update solved it.

I'm confirming that CPU scaling still does not work in Edgy with either the 686 or 386 images. I'm running an Inspiron 8600 Petium M 2.0 GHz. Both max_frep_scaling and min_freq_scaling are stuck at 600 MHz. Trying to set this manually via:

sudo cat cpuinfo_max_freq > scaling_max_freq

results in:

bash: scaling_max_freq: Permission denied

even though scaling_max_freq is writable by root. As suggested, I also tried:

sudo echo 1 > /sys/module/processor/parameters/max_cstate

and this also results in a "Permission denied" error. I've been having issues compiling the kernel so I haven't tried the patch that was posted above yet, but I'll try to do so later in the week.

I tried setting max_cpu_freq manually again logged in as root (no sudo) and I no longer got the "Permission denied" error but the max_cpu_freq still did not change.

Fjodor, throttling and scaling *are not the same*, as I noted before. Throttling has nothing to do with this bug. Please don't discuss it here.

John, I'm rather certain that the max_freq cannot be set manually. If max == min, then you probably have the race condition problem that this bug is discussing. If it doesn't resolve by itself, you could try commenting out the relevant checks in the kernel, as I discussed earlier in the bug. Your sudo command didn't work because of order-of-operations problems (what you wrote was essentially (sudo (echo 1)) > /file from an order of operation standpoint). But you might want to look into a howto on cpufreq operation, because it does not appear that you are going about setting it up in the right way.

fishwithapipe, your problem is not related to this bug.

slazZ, in the worst case, you can do what I discussed (I didn't post a patch because it was too much of a kludge):

"The problem occurs in the verification steps of __cpufreq_set_policy in cpufreq.c. If one comments out that (from after the memcpy to before the data->min = policy->min), cpufreq works fine."

If you look at that code, you should be able to find the portions that need to be commented out. If I recall correctly, the basic idea was to comment out the part where the driver checked the PPU for the maximum frequency it allowed.

Using Constantine's recommendation for "fixing" the kernel I have managed to get cpu scaling to work. Its certainly no permanent solution though.

This bug is also present in the 2.6.18 kernel from kernel.org

Hi, I know I came late in this discussion. After upgrading to Edgy, my freq. scaling broke down. And my processor runs at full speed all the time (I have a Dell Inspiron 5160, P4 3.06 Mhz).
I got this bug with both 386 and generic linux image 2.17 branch (neverthless to say that with Dapper and 2.15 everything was going fine).

I solved the problem re-installing powernowd (I'm not actually sure if it's necessary) and adding by hand the p4-clockmod module to the kernel by:
sudo modprobe p4-clockmod

and adding it to /etc/modules file.

Hope this can help someone

Please read the comments here before adding your comments, and *don't add your experience if you are having an unrelated bug*. Dragonmirov, your bug has nothing to do with this problem.

John, I might take a look at the problem again, but because of its intermittent nature I am not experiencing it right now, and so it is difficult for me to work on.

I have Thinkpad X31 with Pentium M 1.4 GHz and I don't have any problems with cpu frequency scaling in dapper and edgy.

I didn't modify anything (or I can't remeber that). Just the basic installation.

I have a Dell Latitude D600 with a Pentium-M 1.4Ghz. I applied the modified patch posted here and had no success. I also tried the 2.6.18 kernel on a whim and that did not solve the issue either.

Dan: if you have a separate machine, please can you file a separate bug report. It's likely that your issue maybe to do with eg. incompletely ACPI tables in that laptop.

Dan, please *don't* file another bug. I'm not sure what Paul is trying to say, but the D600 is one of the machines that has this problem, and is the machine I used to examine the bug. It has also rather been seen that the patch doesn't fix it, but unfortunately it is very difficult to work on because it appears to be an obscure race condition that appears and disappears, and I haven't had it in quite a long time.

If you are comfortable with doing so, try my method listed earlier: comment out the verification steps in __cpufreq_set_policy in cpufreq.c. You need to keep the ACPI PPC from being used to limit the maximum frequency. This applied to 2.6.15, so you might need to make some changes to the process for it to work on newer kernels.

I finally upgraded to dapper, and I do NOT have any problems :), scaling
works fine as before, as well as everything else.

I have a Thinkpad X31 2673-CBU , with Intel Pentium M (Banias) 1.4 GHz.
My kernel is now:

matteo@host:~$ uname -a
Linux host 2.6.15-27-386 #1 PREEMPT Sat Sep 16 01:51:59 UTC 2006 i686 GNU/Linux

http://www-307.ibm.com/pc/support/site.wss/quickPath.do?quickPathEntry=2673CBU
http://www.thinkwiki.org/wiki/User:Piccobello

Constantine,

I tried your method of commenting out on the 2.6.17-10 kernel and it works.

I must say, this bug is the worst I have worked with. I had thought that the patches that were included in 2.6.17 fixed the issue, but the PPC commenting method still works to solve the issue, it is apparent that the bug still exists.

I have a few thoughts about how the bug might be solved, but none of my ideas are without disadvantages. It would not be overly difficult to write a patch that, if a Pentium M was detected, and the PPC tried to limit the frequency in this way (min_freq==max_freq), would cause the PPC's advice to be ignored. However, there is a possibility that this would not solve the problem for everyone, and it is also possible that it would cause problems for others. It might prove to be hard to maintain, as well, since I do not believe that such a patch would be considered suitable for inclusion in the vanilla kernel.

Unfortunately, I still don't understand *why* the PPC gives this false information. Does anyone have any ideas?

I can confirm this bug on my Pentium M

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Pentium(R) M processor 2.00GHz
stepping : 8
cpu MHz : 800.000
cache size : 2048 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov$
bogomips : 3996.07

I'm currently running Ubuntu Edgy, kernel 2.6.17-10-generic.

With the new edgy generic kernel, everything works like a charm on my new(er) laptop. 1.6Ghz Pentium M, Inspiron 6000D.

Arthur, it appears that this bug shows up somewhat randomly, and is not necessarily reproducible even with the same hardware and software configurations. I had the bug for months, and then it went away without explanation. Others have it even with newer kernels.

Mirco, you should look at scaling_max_freq, scaling_min_freq, cpufreq_max_freq and cpufreq_min_freq, all in /sys/devices/system/cpu/cpu0/cpufreq. If scaling_max_freq is not the same as scaling_min_freq, then you are not experiencing this bug, and have another issue. If you do have this bug, then you might want to try my suggestion detailed in previous comments about commenting out the PPC frequency limiting code if you are comfortable with doing so.

They are the same (800000) :-(

If you need any other detail don't hesitate to ask!

Ahhh!!!

Oddly enough, today, everything works perfectly!!! :-S

I swear I didn't change anything!!!

What I've written previously is incorrect. In fact, I set /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor to performance, the CPU boomed up to 2GHz and, after ~ one second, the clock sank down to 800MHz again...

Not only that, I had a look in /proc/cpuinfo and I still get the CPU MHz bug!

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Pentium(R) M processor 2.00GHz
stepping : 8
cpu MHz : 800.000
cache size : 2048 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov$
bogomips : 3996.01

Please, help me on this, I'm using a 2Ghz CPU at less than a half of its power!!!

... btw, this is my output for dmesg and lsmod.

Mirco - unfortunately, the bug is in an obscure part of the cpufreq code, and dmesg and lsmod don't show anything abnormal. The bug _does_ have a tendency to randomly appear and disappear. You might want to try resetting the BIOS, perhaps that will help.

I suppose if you blacklisted all of the cpufreq code, it might solve the problem, though of course you would have no frequency scaling. You could also use my hackish fix. In addition, I'm thinking about writing the safer fix that I outlined earlier. Unfortunately, I have no way of knowing whether it will work or not (my computer randomly stopped having the bug about 6 months ago), so you would need to test the kernel. Luckily, we are both running Edgy. I'll try to do this in the next few days.

Ok,

I have solved the problem...

My pc is an Lenovo (IBM) Z60m so i guess similar machines have the same problem.
To solve it just set the Adaptive Thermal Management in the BIOS to "Maximize Perfomance".

Hope this can help...

Thank you, Mirco - that confirms some suspicions I had. I think I might be able to reproduce the problem now.

Good!

If you need any other info don't hesitate to ask!

I have a Thinkpad T60 and am experiencing this problem (scaling_max_freq == cpuinfo_min_freq) and I'm not able to change it. I managed to reproduce it in my (uptodate) Edgy install, with an Edgy desktop CD and also with a Feisty Herd 1 CD.

This issue is really concerning because most people that have this issue won't realize it; they will only notice that Ubuntu runs slower than other operating systems on their computer.

This is a similar issue http://bugzilla.kernel.org/show_bug.cgi?id=7060

It may as well be what I'm experiencing since I had the battery unplugged during all tests I did. Unfortunately I don't have my notebook with me now, so I'll only be able to do more tests later today.

Could http://lists.linux.org.uk/mailman/private/cpufreq/2006-June/005961.html also be related?

I did more tests yesterday and the issue I have is in fact the same reported in http://bugzilla.kernel.org/show_bug.cgi?id=7060 . Although the effect is the same, they seem to be caused by different bugs, so I'll file another one and link it to the above mentioned upstream bug.

Please retest against 2.6.20-2 when it is available in the feisty archive.

I have the same problem on my Dell Inspiron 9300. The "scaling_max_freq" and "scaling_min_freq" contain exactly the same values (800000) and my CPU is running at 800Mhz. I run under Edgy with the 2.6.17-10-generic kernel. I tried the "cs_state" fix and it does work (permission not granted). Any (good) fix yet ?

I tested with these kernel and they have the problem too:

Feisty 2.6.20-2
Feisty 2.6.19-* (I don't remember, but it's the last one)
Dapper 2.6.15-27 (not sure, but it's the last one too)

I tested them on my same Edgy (I just updated the kernel).

It is strange because I remember that it was working fine few weeks ago. Can it be something else than the kernel or is this a random kernel bug ?

After testing some solutions, I tested a "sudo modprobe acpi" and got the message attached to this post. Any hint ?

On Wed, 2006-12-20 at 18:58 +0000, Félix C. Morency wrote:
> After testing some solutions, I tested a "sudo modprobe acpi" and got
> the message attached to this post. Any hint ?

sudo modprobe -r speedstep-centrino
sudo modprobe acpi-cpufreq

This should be fixed in the next kernel upload.

Thank for your reply. I tried to do what you told me but:

sudo modprobe -r speedstep-centrino
FATAL: Module speedstep_centrino is in use.

so I tried "sudo modprobe acpi-cpufreq" and:

FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.17-10-generic/kernel/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.ko): Device or resource busy

Any clue ? It is very nasty not to have my cpu running at its maximum freq. I also tested the 386 kernel version but it's all the same.

I also tried a vanilla kernel 2.6.19 that I downloaded from www.kernel.org and it is the same, the bug is present !

I had this problem with a Dell Inspiron 9200 (pentium m 1.7 GHz) with Edgy (kernel 2.6.17-10-generic). But now everything works fine.

I had scaling_max_freq = scaling_min_freq = 600000 and I was unable to change i :

nacim@nacim-laptop:~$ sudo -i
root@nacim-laptop:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
600000
root@nacim-laptop:~# echo 1700000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
root@nacim-laptop:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
600000

As a consequence the scaling didn't work like it used to, about one month ago. I noticed that under Windows everything worked fine but when I played games the GPU was hotter than usual (65°C instead of 40°C). And in fact, the GPU fan didn't work at all. The CPU was also slightly hotter (45°C vs 40°C).

I cleaned my laptop and got rid of the dust that was preventing the GPU fan from spinning. Now, temperatures while gaming are normal. With Ubuntu, scaling_max_freq = 1700000, and the frequency scaling works correctly.

I'm not skilled enough to explain why an abnormally hot temperature of the GPU, or the fact that its fan doesn't spin, makes the CPU run at the lowest available frequency using Ubuntu (scaling worked with Windows). I can only suppose that some hardware device, or the BIOS, gives a wrong scaling_max_freq to the kernel to prevent parts of the hardware from being overheated. But it doesn't explain why, when something goes wrong with the GPU, the CPU is affected.

I hope this will help understanding this bug and the fact that it seems to appear randomly.

Latest feisty kernel no longer has the speedstep-centrino. Using acpi_cpufreq now.

Should fix things.

For some reason, my comment I thought I had made a few days ago didn't show up here.

The issue wasn't in speedstep-centrino, it was in the ppc code of acpi, acpi_processor_ppc_notifier. My hack of commenting out code in the speedstep-centrino code was to keep the acpi code from being used to limit the frequency, and it is quite probable that acpi_cpufreq uses this code as well.

Nacim Rahal's comments might point to what is happening, however. It could be that the BIOS is frequency-limiting due to overheating, and then something is happening to cause the limiting to stick even after the overheating. I might be able to test this if I have time next week.

is this bug related? We still have it with kernel 2.6.20 in Feisty:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/71772

That bug has all the same symptoms as this bug, but I don't have the hardware to see if the same hack fixes it.

Please excuse the query, I realise the status has moved to Fix Released.

I've got Feisty X86_64 and cpufreq also doesn't work properly. I have a Core 2 Duo E6300 over-clocked to 3.15GHz but the recognised freq's are 2.0 & 2.333GHz. It seems to me that it's not reading the fsb correctly as these figures follow the x6 & x7 multipliers. When at standard clocks it is the same story but with lower figures.

If this is irrelevant to this bug please let me know where to post & what information is required.

Thank you.

PS. Couple of questions:
Is it actually setting the displayed frequency's, or is it simply a misreading?
How can scaling be stopped, I've stopped the powernow & acpi services, I've also blacklisted acpi-cpufreq to no effect.