[GUTSY] cpu freq scaling not working anymore

Bug #132271 reported by Christophe Dumez
68
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
Medium
Colin Ian King
Nominated for Gutsy by Sven Thiele
linux-source-2.6.22 (Ubuntu)
Won't Fix
Low
Unassigned
Nominated for Gutsy by Sven Thiele

Bug Description

I noticed that my cpu frequency scaling was broken recently. This is annoying because I have a 1.86Ghz and instead of being stuck at this speed, it is stuck at minimum speed (800 Mhz).

I saw this in my dmesg (may be the problem):
 ACPI Error (utglobal-0126): Unknown exception code: 0xFFFFFFFE [20070126]
[ 36.836000] ACPI Exception (video-1644): UNKNOWN_STATUS_CODE, Cant attach device [20070126]
[ 36.836000] ACPI: Video Device [PEG] (multi-head: yes rom: no post: no)

Here is for powernowd:
root@chris-laptop:/home/chris# /etc/init.d/powernowd restart
 * Stopping powernowd: [ OK ]
 * Starting powernowd... /etc/init.d/powernowd: 156: cannot create /sys/devices/system/cpu/cpu0//cpufreq/scaling_governor: Directory nonexistent
 * CPU frequency scaling not supported

This used to work very well... I will attach my dmesg output here. Please tell me what information I should give you.

Revision history for this message
Christophe Dumez (hydr0g3n) wrote :
Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

I booted back on an "old" kernel 2.6.20-15 and my cpu freq scaling was back. However I still have the same warning in dmesg about ACPI (so this is another problem) but powernowd is now running just fine. Hence, the problem was definitely introduced in 2.6.22 kernel.

I'll upload my dmesg with 2.6.20 to see the difference.

Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

Also, it used to work with previous 2.6.22 kernels. Thus, this was probably broken in one of the latest bugfix releases I think.

Revision history for this message
Amit Kucheria (amitk) wrote :

Could you confirm if the problem still exists with the Tribe 4 live cd?

Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

Well I can't test Tribe4 live cd because it is a too big download for my current internet connection I'm afraid. However, I'm already using latest GUTSY and Yes I do still have this problem.

My kernel is this one: Version: 2.6.22-9.25

I 've now switched back to the following one (luckily I kept it because of sound problems with 2.6.22) while waiting for the fix:
root@chris-laptop:/home/chris# uname -a
Linux chris-laptop 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux

And this one works (cpu freq scaling). I didn't change anything apart from the kernel that is running so that definitely comes from it.

Revision history for this message
Sven Thiele (sthiele) wrote :

I can confirm this for tribe 4
I have a Intel(R) Pentium(R) M processor 1.80GHz which is running with only 600MHz.

Also while booting i got this message.
* CPU frequency scaling not supported

Revision history for this message
Sven Thiele (sthiele) wrote :

I just update to 2.6.22-10 and the issue remains.

Revision history for this message
Christophe Dumez (hydr0g3n) wrote : Re: [Bug 132271] Re: [GUTSY] cpu freq scaling not working anymore

Issue remains here too. Anything we could provide to help? this bug is very
annoying.

On 8/23/07, Sven Thiele <email address hidden> wrote:
>
> I just update to 2.6.22-10 and the issue remains.
>
> --
> [GUTSY] cpu freq scaling not working anymore
> https://bugs.launchpad.net/bugs/132271
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Tor Harald Thorland (linux-strigen) wrote :

I have the same problem. Stuck at 800Mhz on a Dell Inspiron 9300.
Found this in dmesg... but not the things you had.
[ 28.157214] Early unpacking initramfs... done
[ 28.881642] ACPI: Core revision 20070126
[ 28.881724] ACPI: Looking for DSDT in initramfs... error, file /DSDT.aml not found.
[ 28.886449] CPU0: Intel(R) Pentium(R) M processor 1.86GHz stepping 08
[ 28.886489] Total of 1 processors activated (1598.18 BogoMIPS).
[ 28.886686] ENABLING IO-APIC IRQs
[ 28.886912] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
[ 29.032187] Brought up 1 CPUs
[ 29.032364] Booting paravirtualized kernel on bare hardware
[ 29.032448] Time: 22:12:21 Date: 08/13/107
[ 29.032481] NET: Registered protocol family 16
[ 29.032604] EISA bus registered
[ 29.032622] ACPI: bus type pci registered
[ 29.070198] PCI: PCI BIOS revision 2.10 entry at 0xfbaae, last bus=4

Attached is the whole dmesg.
Linux version 2.6.22-11-generic

Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

3 people reported this annoying problem and still no news. It would be nice if someone looked into it :) I'm willing to provide you with the information you need, even if it means recompiling my kernel with some kind of debug enabled (or some patches). linux-source-2.6.20 is working fine, something must have changed after that.

Revision history for this message
Sven Thiele (sthiele) wrote :

Update to gutsy beta now with kernel (Ubuntu 2.6.22-12.39-generic). The Issue remains, I attached my dmesg output.
When I tested the prereleases of Feisty I had similar problems. If I remember correctly it turned out that some Intel patches where not applied to the kernel. https://launchpad.net/linux/+bug/93331

Anyway, I still hope this problem gets fixed till the release of gutsy. ;)

Sven Thiele (sthiele)
Changed in linux-source-2.6.22:
assignee: nobody → ubuntu-kernel-team
status: New → Confirmed
Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

Note: It also affect vanilla kernel. I tried 2.6.23rc6 without success.

On 9/29/07, Sven Thiele <email address hidden> wrote:
>
> ** Changed in: linux-source-2.6.22 (Ubuntu)
> Assignee: (unassigned) => Ubuntu Kernel Team (ubuntu-kernel-team)
> Status: New => Confirmed
>
> --
> [GUTSY] cpu freq scaling not working anymore
> https://bugs.launchpad.net/bugs/132271
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
jms (jmschlenker) wrote :

Same problem with a Dell D420 with
Linux top 2.6.22-12-generic #1 SMP Sun Sep 23 18:11:30 GMT 2007 i686 GNU/Linux
Strangely scaling works for a little while after reboot, then not.

Revision history for this message
jms (jmschlenker) wrote :

Sorry but my previous post was an error. On my machine the cpu did not scale simply
because the strigi-daemon was using lots of cpu. I removed it and everything is now
in order.

Revision history for this message
Tor Harald Thorland (linux-strigen) wrote :

Just a update from me... It is still present in my Linux-generic 2.6.22.13.19 (Which I updated gutsy with yesterday)
Is it possible to lock it to full speed in any way? Better than have the feeling of sitting on a pentium 2 with vista...

Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

Same here. I would be very interested in a way to lock the cpu at full speed
while this is fixed. My 800Mhz is kind of sluggish :)

Tor Harald Thorland> Have you tried to use kernel 2.6.20? it works for me.

On 10/8/07, Tor Harald Thorland <email address hidden> wrote:
>
> Just a update from me... It is still present in my Linux-generic
> 2.6.22.13.19 (Which I updated gutsy with yesterday)
> Is it possible to lock it to full speed in any way? Better than have the
> feeling of sitting on a pentium 2 with vista...
>
> --
> [GUTSY] cpu freq scaling not working anymore
> https://bugs.launchpad.net/bugs/132271
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

I may have an explanation for my cpufreq problem. I read that a dying CMOS battery could cause such problems. My CMOS battery is low, indeed : I got a message on boot about this some time ago. However, I have a laptop (Fujitsu-siemens Amilo M 6453g) and I couldn't find the CMOS battery : so I can't change it... Anyway, for some reason kernel 2.6.20 still manages to adapt my cpu speed (although 2.6.22 and Windows XP can't anymore). It would be iinteresting to know why 2.6.20 is less "sensitive" and maybe try to get this behaviour back in recent kernel.

My laptop is only one year old and the CMOS battery is already dead. Plus, I opened the laptop and I couldn't find it... Maybe there is no way to change it... I contacted user support from the website and I got no answer.

Revision history for this message
Sven Thiele (sthiele) wrote :

Update to Linux version 2.6.22-14-generic (buildd@vernadsky) (gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #1 SMP Wed Oct 10 06:00:47 GMT 2007 (Ubuntu 2.6.22-14.43-generic),
and the problem persists.

Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

Since I didn't have any news. I decided to have a look at the kernel code. I
compared arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c in 2.6.20 and 2.6.22
and I saw that my cpu's code ("CPU_DOTHAN_C0 / SONOMA") was removed. I wrote a
patch to add it back and now cpu frequency scaling is working again. I tested
my patch on a 2.6.23.1 kernel.

Could someone have a look and see why this code was removed?

description: updated
Revision history for this message
Florian Schröck (mael-reverted) wrote :

i have an Athlon 64 X2 and the frequency scaling is not working, too.

also using 2.6.22-14-generic

/etc/init.d/powernowd restart
 * Stopping powernowd: [ OK ]
 * Starting powernowd... /etc/init.d/powernowd: 156: cannot create /sys/devices/system/cpu/cpu0//cpufreq/scaling_governor: Directory nonexistent
 * CPU frequency scaling not supported

:(

but my problem seems a bit different - i get the full 2,2 GHz but it's not getting lower

Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

Apparently the hard-coded frequency tables for SONOMA CPUs were never included in main kernel (from kernel.org). Hence it was probably a patch from Ubuntu. Why was it dropped in 2.6.22? There is at least one user for who it worked better with the patch :)

Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

Edited Ubuntu file is available here : http://bugzilla.kernel.org/attachment.cgi?id=13171
It was in 2.6.20 kernel from Feisty.

More informations here: http://bugzilla.kernel.org/show_bug.cgi?id=7607

Revision history for this message
Bungaman (thisisabreachofprivacy) wrote :

I updated from Feisty with working cpu scaling to Gutsy on 16/10 and now have no cpu scaling. Powernowd returns the same message:

* Stopping powernowd: [ OK ]
* Starting powernowd... /etc/init.d/powernowd: 156: cannot create /sys/devices/system/cpu/cpu0//cpufreq/scaling_governor: Directory nonexistent
* CPU frequency scaling not supported

Revision history for this message
Bungaman (thisisabreachofprivacy) wrote :

Shouldn't the Importance go up? If the patch isn't applied in the final release then people with the sonoma cpu will be working at 600Mhz. Lucky my Feisty kernel was kept during the upgrade so I'm using that one for now.

Revision history for this message
Crashmaxx (crashmaxx) wrote :

Also having this problem. Just upgraded to Gutsy, now my Dell 600m is stuck at 600Mhz.

Revision history for this message
bJXjLjEHIaWT0tFd (bjxjljehiawt0tfd-deactivatedaccount) wrote :

Can confirm this for the gutsy release and my (presumably Dothan?) Pentium M.

bobbeldorsch% uname -a
Linux bobbeldorsch 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

bobbeldorsch% cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Pentium(R) M processor 1.80GHz
stepping : 6
cpu MHz : 600.039
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 mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe up est tm2
bogomips : 1201.27
clflush size : 64

bobbeldorsch% sudo modprobe speedstep-centrino
FATAL: Error inserting speedstep_centrino (/lib/modules/2.6.22-14-generic/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.ko): No such device

bobbeldorsch% sudo modprobe acpi-cpufreq
FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.22-14-generic/kernel/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.ko): No such device

some dmesg output:

[ 0.000000] Detected 600.039 MHz processor.

[ 23.025452] Checking if this processor honours the WP bit even in supervisor mode... Ok.

[ 23.105913] CPU: After generic identify, caps: afe9fbbf 00000000 00000000 00000000 00000180 00000000 00000000
[ 23.105941] CPU: L1 I cache: 32K, L1 D cache: 32K
[ 23.105948] CPU: L2 cache: 2048K
[ 23.105955] CPU: After all inits, caps: afe9fbbf 00000000 00000000 00002040 00000180 00000000 00000000

[ 24.180578] CPU0: Intel(R) Pentium(R) M processor 1.80GHz stepping 06

Let me know if you need more information

Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

Yes Dothan cpus may have problems too. Both SONOMA and DOTHAN tables were
removed.

Looks like there are many computers that experience problem with speed
detection though ACPI. Would be interesting to get the patch back in the
kernel.

On 10/23/07, Niels Ganser <email address hidden> wrote:
>
> Can confirm this for the gutsy release and my (presumably Dothan?)
> Pentium M.
>
> bobbeldorsch% uname -a
> Linux bobbeldorsch 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007
> i686 GNU/Linux
>
> bobbeldorsch% cat /proc/cpuinfo
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 6
> model : 13
> model name : Intel(R) Pentium(R) M processor 1.80GHz
> stepping : 6
> cpu MHz : 600.039
> 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 mce cx8 apic sep mtrr pge mca
> cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe up est tm2
> bogomips : 1201.27
> clflush size : 64
>
> bobbeldorsch% sudo modprobe speedstep-centrino
> FATAL: Error inserting speedstep_centrino
> (/lib/modules/2.6.22-14-generic/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-
> centrino.ko): No such device
>
> bobbeldorsch% sudo modprobe acpi-cpufreq
> FATAL: Error inserting acpi_cpufreq
> (/lib/modules/2.6.22-14-generic/kernel/arch/i386/kernel/cpu/cpufreq/acpi-
> cpufreq.ko): No such device
>
> some dmesg output:
>
> [ 0.000000] Detected 600.039 MHz processor.
>
> [ 23.025452] Checking if this processor honours the WP bit even in
> supervisor mode... Ok.
>
> [ 23.105913] CPU: After generic identify, caps: afe9fbbf 00000000
> 00000000 00000000 00000180 00000000 00000000
> [ 23.105941] CPU: L1 I cache: 32K, L1 D cache: 32K
> [ 23.105948] CPU: L2 cache: 2048K
> [ 23.105955] CPU: After all inits, caps: afe9fbbf 00000000 00000000
> 00002040 00000180 00000000 00000000
>
> [ 24.180578] CPU0: Intel(R) Pentium(R) M processor 1.80GHz stepping 06
>
> Let me know if you need more information
>
> --
> [GUTSY] cpu freq scaling not working anymore
> https://bugs.launchpad.net/bugs/132271
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Tom Winterhalder (thwint) wrote :

I have the same problem on my fujitsu-siemens e8410 with a dual core cpu. It is just blocked at 800 MHz.

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU T7100 @ 1.80GHz
stepping : 13
cpu MHz : 800.000
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
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 sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 3594.54
clflush size : 64

Revision history for this message
Tom Winterhalder (thwint) wrote :

According cpufreq-info the cpu is known correctly, but it seems, that a policy is blocking the speed between 800 and 800 MHz

What looks cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to <email address hidden>, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which need to switch frequency at the same time: 0 1
  hardware limits: 800 MHz - 1.80 GHz
  available frequency steps: 1.80 GHz, 1.80 GHz, 1.20 GHz, 800 MHz
  available cpufreq governors: userspace, conservative, ondemand, powersave, performance
  current policy: frequency should be within 800 MHz and 800 MHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz (asserted by call to hardware).
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which need to switch frequency at the same time: 0 1
  hardware limits: 800 MHz - 1.80 GHz
  available frequency steps: 1.80 GHz, 1.80 GHz, 1.20 GHz, 800 MHz
  available cpufreq governors: userspace, conservative, ondemand, powersave, performance
  current policy: frequency should be within 800 MHz and 800 MHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz (asserted by call to hardware).

Revision history for this message
bJXjLjEHIaWT0tFd (bjxjljehiawt0tfd-deactivatedaccount) wrote :

I could "solve" this issue by resetting my BIOS (version 1.08) to optimal defaults on my Uniwill 259IA. So reports of a buggy BIOS causing this seem to be right. However, I think it might still be sensible to hardcode some frequency tables into the kernel as a fallback since many people don't even know what a BIOS is and for those who do, a BIOS update still is a very, very scary thing.

Revision history for this message
Thomas S Hatch (thatch45) wrote :

Also it is pertinent to keep in mind that for many of us we do not have a bios update available, Gateway has never released a single update to my laptop's bios. Heck if I could update my bios I wouldn't consider this a bug! All it needs are a few more freq tables hard coded into the kernel, and they were working in Feisty.

Revision history for this message
Sven Thiele (sthiele) wrote :

Can you elaborate on how you did this?
I've got the same board.

On Saturday 27 October 2007 21:30:10 Niels Ganser wrote:
> I could "solve" this issue by resetting my BIOS (version 1.08) to
> optimal defaults on my Uniwill 259IA. So reports of a buggy BIOS causing
> this seem to be right. However, I think it might still be sensible to
> hardcode some frequency tables into the kernel as a fallback since many
> people don't even know what a BIOS is and for those who do, a BIOS
> update still is a very, very scary thing.

Revision history for this message
Tor Harald Thorland (linux-strigen) wrote :

I find it really strange that Ubuntu is not taking action on this...
I have a Dell Inspiron 9300, and 2 seconds ago also upgraded to the latest Bios.. it is still stuck at 800Mhz.
I thought that Dell is shipping new computers with Ubuntu... wonder how that will be when they start to put Gutsy on them... Are they also going to be stuck at minimum speed?
There are many people here now with these problems on various computers.. How hard can it be to apply the patch again which aparentlly was there before?
This is a really really show stopper, and Upgrade manager should have had a Degrade button as well for us that are so unlucky that we have upgraded, and is not too familliar with linux that we can solve it without braking anything.
Please if there is anything we can supply to verify, or track these issue down please ask for any info.
(Starting to be a little impatient here)

Revision history for this message
DeusEx (boulevard-of-stars) wrote :

Same problem here: i've got an Athlon 64 3200+, but no freq scaling anymore (worked until upgraded to gutsy), nor frequency scaling governor.

Some infos:

$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 12
model name : AMD Athlon(tm) 64 Processor 3200+
stepping : 0
cpu MHz : 2210.794
cache size : 512 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow up
bogomips : 4436.51
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp

$ ls /sys/devices/system/cpu/cpu0/
cache crash_notes topology

Revision history for this message
Daniel Swarbrick (pressureman) wrote :

As somebody who used to be affected by this bug, I can say with a reasonable level of certainty, that your BIOS (in particular the ACPI code) is buggy. The speedstep-centrino frequency table hack was marked as deprecated in an earlier kernel (sometime around 2.6.18), and newer kernels use ACPI for setting frequency/voltage. This is not Ubuntu's fault. If you want to complain to someone, look further upstream to the kernel developers - but good luck, because I doubt they'll listen. The real bug lies with your BIOS vendor, and flaky ACPI code.

If you want to mimic the behaviour of Feisty, look to the linux-phc project at https://www.dedigentoo.org/trac/linux-phc/

This is essentially the patch that the Ubuntu kernel team added, to ensure frequency scaling would work. In future kernels, speedstep-centrino will be removed completely, so you can kinda see why this patch has not been applied to Gutsy.

Revision history for this message
DeusEx (boulevard-of-stars) wrote :

My bad: my MoBo's BIOS somehow restored to factory defaults so that the Cool'n'Quiet got disabled.
Now i turned it on again, and everything works like a charme.
Sorry for my misleading report.

Revision history for this message
samnmax (aleixmercader) wrote :

I have the same problem. After upgrading to Gutsy, speedstep doesn't work. Pentium M 725 is stuck at 1600MHz.

I tried this:

# modprobe speedstep-centrino
FATAL: Error inserting speedstep_centrino (/lib/modules/2.6.22-14-generic/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.ko): No such device
# modprobe acpi-cpufreq
FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.22-14-generic/kernel/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.ko): No such device

This is with the standard Gutsy kernel, 2.6.22-14. The upgrade program left the old feisty kernel (2.6.20-16), that works OK.

On WinXP or Vista it is also stuck at 1600 at a default install. I must use other programs like NHC or RMclock to change speed. So maybe ACPI is broken on this laptop (AHTEC Signal X-9600M, wich is a Quanta Z500N).

Attached dmesg. note the lines:
ACPI: Invalid _PSS data: freq is zero

I understand that it worked before because of hardcoded speed and voltage tables in speedstep-centrino, that are deprecated in the new kernel. Is there a chance to get it fixed/patched on the next kernel revision? If not I will be hearing this annoying fan forever... :)

Revision history for this message
Daniel Swarbrick (pressureman) wrote :

@samnmax: As I have already said, the bug does not lie within the kernel - you have a buggy ACPI BIOS. This is why you require NHC or similar in Windows. If your ACPI BIOS was correct, then frequency scaling would be working for you in both Linux and Windows.

speedstep_centrino is DEPRECATED. It will be removed altogether in future kernels. The only reason that it worked for you in Feisty is that the Feisty kernels had the Dothan frequency table patches added to speedstep_centrino.

The preferred way of setting frequency/voltage is via ACPI P-states, and this is how the kernel will do it in future (for Intel CPUs at least).

If for some reason you are unable to get a BIOS update to correct your buggy ACPI, your only option is to compile your own patched kernel, using the patches available at https://www.dedigentoo.org/trac/linux-phc/

Look on the bright side - my CPU (1.6 GHz) was stuck at 600 MHz until I got an updated BIOS to correct the ACPI bug.

Revision history for this message
Mathias Hasselmann (hasselmm) wrote :

@Daniel Swarbrick: "If for some reason you are unable to get a BIOS update to correct your buggy ACPI"
To my experience this is the most common case, well supported BIOSes with working ACPI tables the exception. So unless Ubuntu gave up on Bug #1, the suggestion to use a custom patched kernel is not even close to being acceptable. If there is a chance, that Ubuntu can work properly on this broken boxes, Ubuntu has to take this chance!

One of the reasons Ubuntu is used and Ubuntu is recommended was its working out of the box behavhior. It was received as THE Linux for the masses. I really hope that mantra hasn't given up in the meantime. There are far too many broken Linux distributions out there already!

Revision history for this message
Daniel Swarbrick (pressureman) wrote :

The problem with continuing to patch for this issue, is that the patch is going to become rather more elaborate when speedstep_centrino is fully removed from the kernel. Up until now, it has simply been a matter of adding frequencing/voltage pair tables to the existing speedstep_centrino. However, upstream maintainers have decided that the correct way to go is ACPI, and thus speedstep_centrino, which is already deprecated, will be totally removed shortly.

Using a "custom patched kernel" is exactly what about 99.9% of Ubuntu users are already using - the vanilla kernel is heavily patched by Ubuntu devs, in order to get that "out of the box behaviour". Ubuntu and Fedora are widely regarded as being distros that heavily patch upstream kernel sources, in comparison to say, Debian.

What do you suggest Ubuntu does about some of the old drivers that are being removed from the kernel? Patch them back in also? There are only so many out-of-tree patches that you can reasonably expect a mainstream distro to maintain. Sooner or later you have to draw the line however. People with niche requirements will simply have to accept that they are heading for patchville, and had better learn how to compile a kernel. It's not that hard, really.

If a particular glitch is affecting a decent percentage of users, I'm sure it will be remedied. Heck, if it affects that many users, it will be flagged upstream as a bug. But this particular issue only seems to be affect a small proportion of users.

If you want to verify some of what I've said in this comment, head on over bugzilla.kernel.org and search for this issue. You'll find it's been blamed on buggy ACPI implementations, several times. Like it or not, that means it's not a bug with the kernel, and the kernel devs have already made up their mind.

Revision history for this message
Mathias Hasselmann (hasselmm) wrote :

Well, even if the kernel guys are very smart guys, they do idiotic things from time to time. So I'd expect Ubuntu's kernel guys to bring in their weight and tell the upstream guy what stupid thing they are doing entirely depending on something as broken as ACPI.

Well, alternatively someone could finally fix the kernel's ACPI support to leave dreamland and deal with real world ACPI crap.

Revision history for this message
Daniel Swarbrick (pressureman) wrote :

I'm guessing from your reply that you have not visited bugzilla.kernel.org and read the background of the problem.

I'll point you in the right direction. There are more that just one "upstream guys" doing "stupid things", but you might want to start with Len Brown, who also works at Intel, so he has a pretty good grasp of the problem and ACPI in general.

If someone decides to fix Linux's broken ACPI support, maybe they could also fix Windows' broken support, and every other OS that implements it as per the ACPI spec.

Oh, and then, go and actually fix the root of the problem, the hardware vendor's ACPI implementation.

Or, you could take up your frustration with your hardware/BIOS manufacturer, and tell them that at least two major operating systems don't work correctly with their ACPI implementation.

Or, apply the linux-phc patches and get on with life. What's the matter, have you never compiled a kernel before? No time like the present to learn how.

Revision history for this message
Mathias Hasselmann (hasselmm) wrote :

Did find any related bug at the kernel's bugzilla. Created my own http://bugzilla.kernel.org/show_bug.cgi?id=9353

> What's the matter, have you never compiled a kernel before? No time like the present to learn how.
The matter is that I've compiled too many kernels (since '98) and that I am sick of this. Well, and I am disapointed by the poor quality of Gutsy.

Revision history for this message
Daniel Swarbrick (pressureman) wrote :

Maybe you only searched open bugs.

http://bugzilla.kernel.org/show_bug.cgi?id=8228
http://bugzilla.kernel.org/show_bug.cgi?id=8245

These bugs are closed/rejected/dupe because of the fact that the fault does not lie with the kernel.

Good luck with this.

Revision history for this message
Mathias Hasselmann (hasselmm) wrote :

Daniel: Thanks alot. Guess the kernel guys were very wrong with assume "the fualt does not lie with the kernel". If you have to patch the BIOS of a large number of notebooks to make them work with Linux. In my opionion clearly Linux is borken, when it directly uses the ACPI specification for implementing its code, without adding this very important requirement:

"Do not depend to closely on the information found in ACPI tables, since most BIOS programmers don't get sufficient time to deliver a good product."

Revision history for this message
Leszek Tarkowski (leszek-tarkowski) wrote :

I think problem is really important. In windows you can easily fix bad
scaling behaviour by using special software. This is not the case in
linux. You have to have patched kernel. I thing ubuntu should fix this
problem. I'm not sure if this is problem just for few notebooks. Many
people could simply miss this bug, not everyone looks at frequency
scaling applet for example. I remember, that for very long time many
distors supported 2.4 and 2.6 kernels due to changes in new line of
kernels. Maybe ubuntu could do the same - keep kernels below 2.6.20
for people with old notebooks?

--
.: Leszek Tarkowski :.

Revision history for this message
Daniel Swarbrick (pressureman) wrote :

How many notebooks does this problem affect? 50? 100? 10,000? Now express that as a percentage of the total users of Ubuntu. That should give you a rough idea of how much time should be allocated to this.

Should Ubuntu also ship older versions of X, for those old laptops that can't handle the newer versions? Maybe an older version of GNOME too, for laptops without so much RAM. We could create a separate version just for these old versions.... give it version number 7.04, and call it "Feisty".

Revision history for this message
Rockfirm Bear (basal) wrote :

Hey guys, wake up!

The prejudice that Linux is still not supporting much hardware, remains stubbornly. And you want to help keeping it current? No good idea, I think.

Support for Laptops is often bad. People owning such a notebook are being excluded from freq scaling then.

I had luck and a BIOS update.

Please put speedstep_centrino into a package which disables ACPI freq scaling and tell the people about. With this, you could give this minority the chance to fix the problem and aren't affecting the majority. Building such a package wouldn't take much time. But you will win many friends.

Revision history for this message
Daniel Swarbrick (pressureman) wrote :

I am not a kernel developer per se, but I am a developer nonetheless, and I have done a bit of kernel debugging back in the early days of 2.6.

I think some people are overlooking the feasibility of continuing to support speedstep_centrino once it has been officially removed from the kernel. This is not some userland app that is kernel-agnostic. This is something fairly core and low level. Once it has been removed upstream, you may find that there aren't even any hooks left in the kernel where a modularised speedstep_centrino could hook into.

I think rather than continue to plead for this to be reinstated, this issue needs the input of a) an Ubuntu kernel maintainer or b) one of the cpufreq kernel developers, to shed light on the technical feasibility of retaining this outdated code.

As I think I've already made fairly clear, the upstream devs have little to no interest in continuing to maintain speedstep_centrino, so it really falls on the Ubuntu kernel maintainers to decide whether they feel like doing this, and whether it can even in fact be done.

Revision history for this message
Petra (peter-frank69) wrote :

I have a 1.83 GHz T2400 Core Duo with 2GB in my Inspiron 9400. I do a lot of math intensive simulation that run for hours. I was running Windows and hit the memory limitation (could only access 1 GB for the application) so switched to Ubuntu. In Ubuntu, the application could access 1.7 GB, but compared to Windows I had about a 33% speed reduction.

I noticed in Linux I was stuck at 1.0 GHz during simulations... cat /proc/cpuinfo

I just wanted the problems fixed... so this is what I did:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

output was: 1833000 1333000 1000000 (the available frequencies I can set my cpu frequency to)

Then I set the cpu frequency to 1833000:

cpufreq-set -f 1833000

Problem solved for me.... Now Linux simulations are 20% faster than Windows

This is just a solution of how to get around it until a decision is made how how to fix this issue.

Revision history for this message
ugaciaka (ugaciaka) wrote :

I have intel dual core E6600 and i read also https://bugs.launchpad.net/ubuntu/+source/powernowd/+bug/124618
but the problem persisting:

 * Starting powernowd... /etc/init.d/powernowd: 156: cannot create /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor: Directory nonexistent
 * CPU frequency scaling not supported

Revision history for this message
ugaciaka (ugaciaka) wrote :

i resolved setting BIOS with speedstep from CPU setting...

Revision history for this message
t-om (t-om-nic) wrote :

Same problem here with Lenovo 3000 Y200 (6469-22R), with Insyde´s BIOS (12/06/05) and gutsy kernel 2.6.22-14-generic as well as with vanilla 2.6.23.8 with linux-phc. Stuck at 600 and 800Mhz with acpi-cpufreq. Without it able to run at full speed. Unfortunately the tables have been removed from the suggested linux-phc 0.3.0 too, so it is no longer a valid remedy.

Revision history for this message
Henrik Nilsen Omma (henrik) wrote :

This will be retargeted towards the Hardy kernel once it is released. I've tagged this as "hardy-kernel-candidate" so that we make sure to retarget this report once the new release is out. However against the linux-source-2.6.22 package this is being marked as "Won't Fix" as it does not meet the criteria for a stable release update. To learn more about the stable release update process please refer to https://wiki.ubuntu.com/StableReleaseUpdates . Thanks!

Changed in linux-source-2.6.22:
importance: Undecided → Low
status: Confirmed → Won't Fix
Revision history for this message
Bungaman (thisisabreachofprivacy) wrote :

I would certainly hope so. In my bios there is no option to enable/disable cpu frequency scaling. That could solve the issue I've read on different places. My only option is to have it enabled in the CPU, hence I'm stuck with a 2.6.20 kernel.

Revision history for this message
Bungaman (thisisabreachofprivacy) wrote :

update: I've just tested and for fujitsu-siemens Amilo M1424 bios version 1.03 you can select "load optimal defaults". For me that fixed to get frequency scaling working with 2.6.22-14-generic. I don't know what novelties 2.6.22 brings over 2.6.20 but I'm glad I'm not stuck anymore.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hardy Heron Alpha2 was recently released. It contains an updated version of the kernel. You can download and try the new Hardy Heron Alpha2 release from http://cdimage.ubuntu.com/releases/hardy/alpha-2/ . You should be able to then test the new kernel via the LiveCD. If you can, please verify if this bug still exists or not and report back your results. General information regarding the release can also be found here: http://www.ubuntu.com/testing/hardy/alpha2 . Thanks!

Changed in linux:
status: New → Incomplete
Revision history for this message
samnmax (aleixmercader) wrote :

Hi, I'm trying the Hardy Heron LiveCD now. The problem is still the same,
Pentium M 1.6 GHz stuck at 1600 and it won't go down. Same problem in
Windows, so in my case it is a BIOS bug of the laptop, a Quanta ZW9 (Ahtec
X-9600M).

I tried this too:
ubuntu@ubuntu:~$ sudo modprobe speedstep-centrino
FATAL: Error inserting speedstep_centrino
(/lib/modules/2.6.24-2-generic/kernel/arch/x86/kernel/cpu/cpufreq/speedstep-
centrino.ko): No such device
ubuntu@ubuntu:~$ sudo modprobe speedstep-smi
FATAL: Error inserting speedstep_smi
(/lib/modules/2.6.24-2-generic/kernel/arch/x86/kernel/cpu/cpufreq/speedstep-
smi.ko): No such device
ubuntu@ubuntu:~$ sudo modprobe speedstep-ich
FATAL: Error inserting speedstep_ich
(/lib/modules/2.6.24-2-generic/kernel/arch/x86/kernel/cpu/cpufreq/speedstep-
ich.ko): No such device
ubuntu@ubuntu:~$ sudo modprobe acpi-cpufreq
FATAL: Error inserting acpi_cpufreq
(/lib/modules/2.6.24-2-generic/kernel/arch/x86/kernel/cpu/cpufreq/acpi-
cpufreq.ko): No such device
ubuntu@ubuntu:~$

So I guess the only solution is the phc patch... :(

2008/1/4, Leann Ogasawara <email address hidden>:
>
> Hardy Heron Alpha2 was recently released. It contains an updated
> version of the kernel. You can download and try the new Hardy Heron
> Alpha2 release from http://cdimage.ubuntu.com/releases/hardy/alpha-2/ .
> You should be able to then test the new kernel via the LiveCD. If you
> can, please verify if this bug still exists or not and report back your
> results. General information regarding the release can also be found
> here: http://www.ubuntu.com/testing/hardy/alpha2 . Thanks!
>
> ** Also affects: linux (Ubuntu)
> Importance: Undecided
> Status: New
>
> ** Changed in: linux (Ubuntu)
> Status: New => Incomplete
>
> ** Tags removed: hardy-kernel-candidate
>
> --
> [GUTSY] cpu freq scaling not working anymore
> https://bugs.launchpad.net/bugs/132271
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Wolfgang Tremmel (launchpad-garf) wrote :

I just used the patch supplied above to patch a vanilla 2.6.24 kernel - works like a charm (I had to apply the patch manually as some things have changed a bit).

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi Wolfgang,

Thanks for the feedback. May I ask where you got the patch from? And do you know if there have been any efforts to get it submitted and accepted into the mainline kernel? It is a lot of extra work for the Ubuntu kernel team to maintain out of tree patches. As such they require evidence of upstream submission before considering to maintain community patches locally. Thanks.

Revision history for this message
Wolfgang Tremmel (launchpad-garf) wrote :

Hello Leann,

sroll up - its the same patch Christophe Dumez supplied on 2007-10-13, simply re-arranged a bit and using a context-diff (so beginners can apply it also to future kernels more easy).
As I am not involved in development I have no idea where to submit this to get it included into the kernel...

best regards,
Wolfgang

Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
status: Incomplete → Triaged
Changed in linux:
assignee: ubuntu-kernel-team → colin-king
Revision history for this message
samnmax (aleixmercader) wrote :

I was able to solve my broken ACPI tables by decompiling and fixing the
DSDT.

The frequency field for the 600 MHz state was 0, hence the line in dmesg:
"ACPI: Invalid _PSS data: freq is zero"

I set it to 600, compiled it again and added it to the initrd. Now I can use
acpi-cpufreq to scale the cpu clock to either 600 or 1600 MHz (not the full
range, but that's enough). It even works in Vista with the DSDT registry
override.

Keep the good work with Ubuntu!

2008/2/13, Colin King <email address hidden>:
>
> ** Changed in: linux (Ubuntu)
> Assignee: Ubuntu Kernel Team (ubuntu-kernel-team) => Colin King
> (colin-king)
>
> --
> [GUTSY] cpu freq scaling not working anymore
> https://bugs.launchpad.net/bugs/132271
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Changed in linux:
status: Triaged → In Progress
Revision history for this message
Colin Ian King (colin-king) wrote :

Added to Ubuntu Hardy development kernel tree (2.6.24)

Changed in linux:
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 2.6.24-8.14

---------------
linux (2.6.24-8.14) hardy; urgency=low

  [cking]

  * Support Novatel U727 EVDO modem: Add pid and vid to
    drivers/usb/serial/airprime.c
    - LP: #150996
  * Enable speedstep for sonoma processors.
    - LP: #132271

  [Stefan Bader]

  * SAUCE: Export dm_disk function of device-mapper

 -- Tim Gardner <email address hidden> Wed, 13 Feb 2008 21:47:18 -0700

Changed in linux:
status: Fix Committed → Fix Released
Revision history for this message
Michael Mc Donnell (michael-mcdonnell) wrote :

> This bug was fixed in the package linux - 2.6.24-8.14
...
> * Enable speedstep for sonoma processors.
> - LP: #132271

Could you fix it for dothan too? I too have had a regression from feisty to gutsy. My cpuinfo says:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Pentium(R) M processor 1.73GHz
stepping : 8
cpu MHz : 600.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 pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe up est tm2
bogomips : 1195.57
clflush size : 64

It will run at a maximum of 1.3 GHz instead of 1.73 Ghz. It underclocks to 600 MHz when it should only underclock down to 800 Mhz.

Revision history for this message
filzstift (filzstift) wrote :

i also need this for a dothan cpu.
with the acpi-cpufreq i have just 2 speedsteps (600mhz and 1.5ghz) and therefore i hear my noisy cpu-fan the whole day :-(

my cpuinfo:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Pentium(R) M processor 1.50GHz
stepping : 6
cpu MHz : 600.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 mce cx8 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe up bts est tm2
bogomips : 1197.84
clflush size : 64

or does anyone have a fixes dsdt for an amilo M 1420 (1.5ghz centrino - dothan???)

cu
         CHristoph

Revision history for this message
franestepona (fransanchezoria) wrote :

Hi

Lot of time have passed by since this thread was started and I have still no fix for this bug. After kernel 2.6.15 my cpu scaling stopped working.

fran@fransmachine:~$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Pentium(R) M processor 2.00GHz
stepping : 6
cpu MHz : 599.963
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 mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe bts est tm2
bogomips : 1201.29
clflush size : 64
fran@fransmachine:~$ sudo modprobe speedstep-centrino
FATAL: Error inserting speedstep_centrino (/lib/modules/2.6.24-12-386/kernel/arch/x86/kernel/cpu/cpufreq/speedstep-centrino.ko): No such device

I dont know how to use the file speedstep-centrino.c, all I have under cpufreq directory is speedstep-centrino.ko, what I am supossed to do with speedstep-centrino.c? Thanks everyone and hope this get fixed soon.

Revision history for this message
Bruce Cowan (bruce89-deactivatedaccount) wrote :

I notice this fix hasn't be pushed upstream, perhaps it should be.

Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

I already tried to talk upstream into it but they would not agree. They consider this is a bug of our BIOSes and not in the kernel. Also, speedstep-centrino is deprecated in the kernel and will probably disappear in the future (If I understood correctly).

Revision history for this message
broesch (broesch) wrote :

I have the same problem only two steps (maximum and minimum) with a Dothan CPU. I tried a feisty live cd and it worked, all 7 steps, on gutsy and hardy only two are working. Is there anything that might be done to fix this?

Revision history for this message
filzstift (filzstift) wrote :

@broesch: i assume that your DSDT or SSDT lists just those two frequencies.
in ubuntu feisty the information for the speed-stepping was included in the kernel (speedstep-centrino.ko) but now speedstepping is done by the module acpi-cpufreq and this module does not provide the info for speedstepping (and it is not the task of the kernel to provide this info - so it is not a kernel bug but a bug in you bios)

i had the same problem on an fujitsu amilo m1420 with an Pentium M 715 (that's a dothan with 1,5ghz). have a look at you DSDT and SSDT table and check if you find information for Speedsteping in those tables. (normaly this info is in an PSS table). if you find just the info for two speedsteps you have to complete the list. (thats a bit tricky..) and then you have to boot linux with you modified DSDT. (if the info for speedsteping is in you SSDT you have to merge your dsdt and ssdt and tell linux not to load the SSDT from the bios at boot)

i plan to write an howto that describes that a bit more detailed
i will post the link here

cu
        CHristoph

Revision history for this message
broesch (broesch) wrote :

@Zaunmayrchris Thanks alot, I'll be waiting for that howto

Revision history for this message
filzstift (filzstift) wrote :

@broesch
well... here it is:
http://s2.enemy.org/~zaunmayc/speedstep8.04.html

the howto is for an amilo m1420 with a intel Pentium M 715 (dothan) cpu. if you don't have exactly the same hardware the howto could at least inspire you to fix you problem.

sry that you had to wait so long for my response.. i hope you can still need the howto

cu
         CHristoph

Revision history for this message
Launchpad Janitor (janitor) wrote : Kernel team bugs

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

Revision history for this message
samnmax (aleixmercader) wrote :

Just a reference for people searching for my laptop model (Ahtec Signal X-9600, Quanta Z500N series, Quanta ZW9):

After years of hesitation -I didn't want to brick my laptop with an incorrect BIOS!- I updated it to version Q3B21 (mine was Q3A12)

I found the BIOS update at:
http://www.lamsystems.com/drivers/notebook/zw9.asp
The file is 9AQ3B21.zip

Turns out Ahtec shipped the laptop with a BIOS incompatible with the Dothan CPU. The PC worked, but features like Speedstep and C2 power state were not working. With the new BIOS they work perfectly and the laptop is quieter than ever!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.