kernel can't scale cpu frequency

Bug #36014 reported by MrFaber on 2006-03-22
Affects Status Importance Assigned to Milestone
linux-source-2.6.15 (Ubuntu)
Ben Collins
linux-source-2.6.17 (Ubuntu)
linux-source-2.6.20 (Ubuntu)

Bug Description

Linux kernels 386 and 686 can't scale cpu frequency. I have tested it on two machines one P4 ULV and a standard P4 M with 1.8 ghz and both times it doesn't work. All modules are loaded and it shows under sys the correct min and max value but you can't change it and powernowd too.

Ben Collins (ben-collins) wrote :

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.

MrFaber (mr-faber-gmx) wrote :

$ 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.

MrFaber (mr-faber-gmx) wrote :

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.

Simon Law (sfllaw) on 2006-05-09
Changed in linux-source-2.6.15:
status: Unconfirmed → Confirmed
Changed in linux-source-2.6.15:
assignee: nobody → jr
importance: Medium → Critical
assignee: jr → nobody
importance: Critical → High
Constantine Evans (cevans) wrote :

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.

Dennis Kaarsemaker (dennis) wrote :

No need to bump severity...

Changed in linux-source-2.6.15:
importance: High → Medium
Constantine Evans (cevans) wrote :

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.

description: updated
Constantine Evans (cevans) wrote :

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.

Constantine Evans (cevans) wrote :

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

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.

Ben Collins (ben-collins) wrote :

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

Changed in linux-source-2.6.15:
assignee: nobody → ben-collins
status: Confirmed → Fix Committed

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?

Constantine Evans (cevans) wrote :

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.

Constantine Evans (cevans) wrote :

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.

Changed in linux-source-2.6.15:
status: Fix Committed → Confirmed
Pedro Martinez-Julia (pedromj) wrote :

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.

Luka Renko (lure) 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, 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, 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.

Constantine Evans (cevans) wrote :

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.

Ken Gallo (ubuntu-gallohouse) wrote :

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:

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.

Constantine Evans (cevans) wrote :

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.

sean finney (sean-stickybit) wrote :

here's a "me too"...

ken, i tried your workaround but no luck :(

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

Ken Gallo (ubuntu-gallohouse) wrote :


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 I tried to install it, but it complained I needed module-init-tools => 3.2.2-3ubuntu2.

I went back to, 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.

Ken Gallo

Luka Renko (lure) wrote :

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.

Changed in linux-source-2.6.17:
status: Unconfirmed → Fix Committed
mvandeg (mvandegiessen) wrote :

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.

juanqui (juan-villa) wrote :

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).

Ben Collins (ben-collins) wrote :

No such thing as 2.6.17 in dapper.

Changed in linux-source-2.6.17:
status: Unconfirmed → Rejected
Ben Collins (ben-collins) wrote :

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

Constantine Evans (cevans) wrote :

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.
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


Changed in linux-source-2.6.17:
status: Fix Committed → Confirmed
Fjodor (sune-molgaard) wrote :

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
   *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
 * 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:~$ sudo modprobe speedstep-centrino
FATAL: Error inserting speedstep_centrino (/lib/modules/ No such devicesune@tommelise:~$


Fjodor (sune-molgaard) wrote :

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

slazZ (slazz) wrote :

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.

fishwithapipe (nofutureforyu) wrote :

i had the

 * CPU frequency scaling not supported


error inserting speedstep-centrino issues on my HP NC8430

Bios update solved it.

John Trimble (trimblej) wrote :

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.

John Trimble (trimblej) wrote :

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.

Constantine Evans (cevans) wrote :

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.

John Trimble (trimblej) wrote :

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

John Trimble (trimblej) wrote :

This bug is also present in the 2.6.18 kernel from

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

Constantine Evans (cevans) wrote :

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.

Dan Backes (dbackes) wrote :

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.

Paul Sladen (sladen) wrote :

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.

Constantine Evans (cevans) wrote :

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.

piccobello (piccobello) wrote :

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

Dan Backes (dbackes) wrote :


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

Constantine Evans (cevans) wrote :

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?

Mirco Briosi (mail-miobio) wrote :

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.

Constantine Evans (cevans) wrote :

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.

Mirco Briosi (mail-miobio) wrote :

They are the same (800000) :-(

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

Mirco Briosi (mail-miobio) wrote :


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

I swear I didn't change anything!!!

Mirco Briosi (mail-miobio) wrote :

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!!!

Mirco Briosi (mail-miobio) wrote :

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

Constantine Evans (cevans) wrote :

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.

Mirco Briosi (mail-miobio) wrote :


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...

Constantine Evans (cevans) wrote :

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

Mirco Briosi (mail-miobio) wrote :


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

Guilherme Salgado (salgado) wrote :

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.

John Trimble (trimblej) wrote :

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.

Guilherme Salgado (salgado) wrote :

This is a similar issue

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.

Guilherme Salgado (salgado) wrote :

I did more tests yesterday and the issue I have is in fact the same reported in . 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.

Ben Collins (ben-collins) wrote :

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

Changed in linux-source-2.6.19:
status: Unconfirmed → Needs Info
Félix C. Morency (colibry10) wrote :

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 ?

Félix C. Morency (colibry10) wrote :

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 ?

Félix C. Morency (colibry10) wrote :

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

Ben Collins (ben-collins) wrote :

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.

Félix C. Morency (colibry10) wrote :

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.

Félix C. Morency (colibry10) wrote :

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

Nacim Rahal (nacnacim) wrote :

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
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

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.

Ben Collins (ben-collins) wrote :

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

Should fix things.

Changed in linux-source-2.6.20:
status: Needs Info → Fix Released
Constantine Evans (cevans) wrote :

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.

Marco Cimmino (cimmo) wrote :

is this bug related? We still have it with kernel 2.6.20 in Feisty:

John Trimble (trimblej) wrote :

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.

ahaslam (anthonyhaslam) wrote :

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.

Changed in linux-source-2.6.15:
status: Confirmed → Fix Released
Changed in linux-source-2.6.17:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers