AMD X2 CPU stuck at 1Ghz lowest speed

[Lafa]

I have a Shuttle with Athlon 64 X2 Dual Core, and with jaunty the CPU the speed is alwyas the lowest speed.
I tried using the cpufreq-selector and the CPU Frenquency Scalling Applet in gnome to changethe speed and the governor, and I was not able to make the CPU speed change to 2.8GHz

lafa@xpc-desktop:~$ cat /proc/acpi/processor/CPU0/*
processor id: 0
acpi id: 0
bus mastering control: no
power management: no
throttling control: no
limit interface: no
<not supported>
active state: C0
max_cstate: C8
bus master activity: 00000000
maximum allowed latency: 2000000000 usec
states:
<not supported>

lafa@xpc-desktop:~$ cat /proc/acpi/processor/CPU1/*
processor id: 1
acpi id: 1
bus mastering control: no
power management: no
throttling control: no
limit interface: no
<not supported>
active state: C0
max_cstate: C8
bus master activity: 00000000
maximum allowed latency: 2000000000 usec
states:
<not supported>

lafa@xpc-desktop:~$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 35
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
stepping : 2
cpu MHz : 1000.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
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 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good pni lahf_lm cmp_legacy
bogomips : 2009.56
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

processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 35
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
stepping : 2
cpu MHz : 1000.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
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 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good pni lahf_lm cmp_legacy
bogomips : 2009.56
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

lafa@xpc-desktop:~$ cat /proc/acpi/fan/FAN/state
status: on
lafa@xpc-desktop:~$ cat /proc/acpi/thermal_zone/THRM/
cooling_mode polling_frequency state temperature trip_points
lafa@xpc-desktop:~$ cat /proc/acpi/thermal_zone/THRM/
cooling_mode polling_frequency state temperature trip_points

lafa@xpc-desktop:~$ cat /proc/acpi/thermal_zone/THRM/*
0 - Active; 1 - Passive
<polling disabled>
state: passive
temperature: 54 C
critical (S5): 60 C
passive: 50 C: tc1=4 tc2=3 tsp=60 devices=CPU0
active[0]: 50 C: devices= FAN
lafa@xpc-desktop:~$ uname -a
Linux xpc-desktop 2.6.28-6-generic #17-Ubuntu SMP Fri Jan 30 15:35:08 UTC 2009 x86_64 GNU/Linux

[Ryan (ryan-redhat-bugs)]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.9) Gecko/20071105 Fedora/2.0.0.9-1.fc9 Firefox/2.0.0.9

Description of problem:
On my Santa Rosa based Fujitsu T4220 notebook the CPU frequency is permanently stuck at 800MHz (actual max is 2GHz) no matter what the load. This occurs no matter which governor is selected (userspace, ondemand, performance etc..).

On resume from suspend to ram, the frequency fluctuates between 800MHz and 1.6GHz for approx. a minute, and then goes back to being stuck at 800MHz.

Version-Release number of selected component (if applicable):
kernel-2.6.24-0.42.rc3.git1.fc9

How reproducible:
Always

Steps to Reproduce:
1. boot into fedora
2. check /cat/proc/cpuinfo ( will be 800MHz )
3. run something cpu intensive
3. check cpuinfo (still stuck at 800MHz)

Actual Results:
The CPU frequency doesn't change

Expected Results:
The frequency should increase to max if needed and go back to min when not.

Additional info:

[Ryan (ryan-redhat-bugs)]

Created attachment 271951
lspci -vv output

[Ryan (ryan-redhat-bugs)]

Created attachment 271961
lspci -vvn output

[Ryan (ryan-redhat-bugs)]

Created attachment 271971
dmidecode output

[Ryan (ryan-redhat-bugs)]

[ryan@tablet ~]$ ls /sys/devices/system/cpu/cpu0/cpufreq/
affected_cpus scaling_available_frequencies scaling_governor
cpuinfo_cur_freq scaling_available_governors scaling_max_freq
cpuinfo_max_freq scaling_cur_freq scaling_min_freq
cpuinfo_min_freq scaling_driver scaling_setspeed

[root@tablet ryan]# cat /sys/devices/system/cpu/cpu0/cpufreq/*
0 1
800000
2001000
800000
2001000 2000000 1600000 1200000 800000
userspace performance
800000
acpi-cpufreq
performance
800000
800000

Also, I am not sure how relevant this is, but
/proc/acpi/processor/CPU0/throttling outputs "<not supported>".

I have the same problems on every linux distro I have tried on this laptop

[Ryan (ryan-redhat-bugs)]

Created attachment 274581
dmesg output

Here's my dmesg

[Jaakko (jaakko-redhat-bugs)]

On updated Fedora 8, on Dell Inspiron 9300 laptop, I have the same problem.
Frequency policy is stuck at 800 MHz. Scaling worked in the past on some
earlier FC, not sure if I paid attention so much on FC7.

# cpufreq-info
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
  hardware limits: 800 MHz - 1.73 GHz
  available frequency steps: 1.73 GHz, 1.33 GHz, 1.07 GHz, 800 MHz
  available cpufreq governors: ondemand, userspace, performance
  current policy: frequency should be within 800 MHz and 800 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.

# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Pentium(R) M processor 1.73GHz
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 mtrr pge mca cmov pat
clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up bts est tm2
bogomips : 1597.42
clflush size : 64

# cat /proc/acpi/processor/CPU0/throttling
state count: 8
active state: T0
state available: T0 to T7
states:
   *T0: 00%
    T1: 12%
    T2: 25%
    T3: 37%
    T4: 50%
    T5: 62%
    T6: 75%
    T7: 87%

[Chuck (chuck-redhat-bugs)]

(In reply to comment #4)
> [ryan@tablet ~]$ ls /sys/devices/system/cpu/cpu0/cpufreq/
> affected_cpus scaling_available_frequencies scaling_governor
> cpuinfo_cur_freq scaling_available_governors scaling_max_freq
> cpuinfo_max_freq scaling_cur_freq scaling_min_freq
> cpuinfo_min_freq scaling_driver scaling_setspeed
>
> [root@tablet ryan]# cat /sys/devices/system/cpu/cpu0/cpufreq/*
> 0 1
> 800000
> 2001000
> 800000
> 2001000 2000000 1600000 1200000 800000

That 2001000 doesn't look right...

Try:

# echo "2000000" >scaling_max_freq

[Ryan (ryan-redhat-bugs)]

(In reply to comment #7)
> (In reply to comment #4)
> > [ryan@tablet ~]$ ls /sys/devices/system/cpu/cpu0/cpufreq/
> > affected_cpus scaling_available_frequencies scaling_governor
> > cpuinfo_cur_freq scaling_available_governors scaling_max_freq
> > cpuinfo_max_freq scaling_cur_freq scaling_min_freq
> > cpuinfo_min_freq scaling_driver scaling_setspeed
> >
> > [root@tablet ryan]# cat /sys/devices/system/cpu/cpu0/cpufreq/*
> > 0 1
> > 800000
> > 2001000
> > 800000
> > 2001000 2000000 1600000 1200000 800000
>
> That 2001000 doesn't look right...

Yeah, I'm not sure about that either.

>
> Try:
>
> # echo "2000000" >scaling_max_freq
>

I've tried that before and it has no effect. I can try echoing anything into
that file as root and it will not change from '800000'

I've noticed a few other people with Fujitsu laptops (not just T4220's) with the
same problem as me. All the machines have the following in their dmesg output:

ACPI: EC: Look up EC in DSDT
ACPI Error (tbinstal-0134): Table has invalid signature [ ], must be SSDT,
PSDT or OEMx [20070126]
ACPI Error (psparse-0537): Method parse/execution failed [\_SB_._INI] (Node
f7801440), AE_BAD_SIGNATURE

I don't know enough about how ACPI works to say whether that has anything to do
with /proc/acpi/processor/CPU0/throttling saying "<not supported>", or if it is
even relevant, but it seems to be a common theme.

[Jaakko (jaakko-redhat-bugs)]

Created attachment 289802
dmesg output of booting with cpufreq.debug=7 option

Line 443 says
"freq-table: verification lead to (800000 - 1733000 kHz) for cpu 0"
which is correct, but line 446 says
"freq-table: verification lead to (800000 - 800000 kHz) for cpu 0"
and cpu remains stuck at 800MHz for me.

[Łukasz (ukasz-redhat-bugs)]

Created attachment 298400
dmesg with options acpi=debug cpufreq.debug=7

[Łukasz (ukasz-redhat-bugs)]

Comment on attachment 298400
dmesg with options acpi=debug cpufreq.debug=7

I have the same problem on a Thinkpad R61i with an up-to-date Fedora 8.

I don't get any of the ACPI errors mentioned earlier but scaling_max_frequency
is also stuck at 800000.
$ echo 1467000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
 doesn't change it.

[Jaakko (jaakko-redhat-bugs)]

About my case, comment #9. This was caused by dust that prevented
the GPU fan from spinning. Works now fine. The root cause was hinted
by running the Dell Diagnostics software that came with the computer.

[Łukasz (ukasz-redhat-bugs)]

It looks like removing both the battery and AC connector had fixed the problem
in my case.

[Bug (bug-redhat-bugs)]

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Lafa (luis-alves)]

The scaling_max_freq and the scaling_min_freq always have the same value, I tried using different governator, I got same results. The scaling_max_freq is always 1000000 instead of 2000000.

root@xpc-desktop:/sys/devices/system/cpu/cpu0/cpufreq# more *
::::::::::::::
affected_cpus
::::::::::::::
0 1
::::::::::::::
cpuinfo_cur_freq
::::::::::::::
1000000
::::::::::::::
cpuinfo_max_freq
::::::::::::::
2000000
::::::::::::::
cpuinfo_min_freq
::::::::::::::
1000000
::::::::::::::
related_cpus
::::::::::::::
0 1
::::::::::::::
scaling_available_frequencies
::::::::::::::
2000000 1800000 1000000
::::::::::::::
scaling_available_governors
::::::::::::::
conservative ondemand userspace powersave performance
::::::::::::::
scaling_cur_freq
::::::::::::::
1000000
::::::::::::::
scaling_driver
::::::::::::::
powernow-k8
::::::::::::::
scaling_governor
::::::::::::::
performance
::::::::::::::
scaling_max_freq
::::::::::::::
1000000
::::::::::::::
scaling_min_freq
::::::::::::::
1000000
::::::::::::::
scaling_setspeed
::::::::::::::
<unsupported>

[Lafa (luis-alves)]

my shuttle is a xps amd st20g5, attached is the dsdt table.

[Lafa (luis-alves)]

is it possible to fix this for Jaunty 9.04

[Jay Modi (jaymode)]

I believe that I am experiencing the same bug (only a little different). My system specs are:
Intel Pentium Dual Core E2180
Abit AB9 Pro Motherboard
4GB Ram
Ubuntu 9.04 64bit

I can get CPU1 to scale to full speed but CPU0 will not scale; it is stuck at the lowest possible speed. I have tried changing the various governors but that did not work.

/sys/devices/system/cpu/cpu0/cpufreq$ sudo grep "." *
affected_cpus:0
cpuinfo_cur_freq:2750000
cpuinfo_max_freq:2750000
cpuinfo_min_freq:1650000
related_cpus:0
scaling_available_frequencies:2750000 2200000 1650000
scaling_available_governors:conservative ondemand userspace powersave performance
scaling_cur_freq:1650000
scaling_driver:acpi-cpufreq
scaling_governor:performance
scaling_max_freq:1650000
scaling_min_freq:1650000
scaling_setspeed:<unsupported>

/sys/devices/system/cpu/cpu0/cpufreq$ cpufreq-info
cpufrequtils 004: 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
  hardware limits: 1.65 GHz - 2.75 GHz
  available frequency steps: 2.75 GHz, 2.20 GHz, 1.65 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 1.65 GHz and 1.65 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.65 GHz.
  cpufreq stats: 2.75 GHz:0.49%, 2.20 GHz:0.66%, 1.65 GHz:98.85% (5)
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which need to switch frequency at the same time: 1
  hardware limits: 1.65 GHz - 2.75 GHz
  available frequency steps: 2.75 GHz, 2.20 GHz, 1.65 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 1.65 GHz and 2.75 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.65 GHz.
  cpufreq stats: 2.75 GHz:15.31%, 2.20 GHz:0.06%, 1.65 GHz:84.63% (123)

[Jay Modi (jaymode)]

Architecture: amd64
DistroRelease: Ubuntu 9.04
HibernationDevice: RESUME=UUID=297bfb6d-34b0-43b9-9cb5-29c07beb3599
MachineType: OEM OEM
NonfreeKernelModules: nvidia
Package: linux-image-2.6.28-11-generic 2.6.28-11.42
PackageArchitecture: amd64
ProcCmdLine: root=UUID=5082e3d5-75b2-4b0d-8c37-b094b3152918 ro quiet splash
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, no user)
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.28-11.42-generic
Uname: Linux 2.6.28-11-generic x86_64
UserGroups:

[schmolch (saschaheid)]

Same problem here on a CoreDuo running 9.10

[Jay Modi (jaymode)]

Other users are also experiencing the same issues, however, some may just think that the Gnome app is broken:
http://ubuntuforums.org/showthread.php?t=1093355

[Jay (jay-redhat-bugs)]

I believe that I am seeing the same type of behaviour in Fedora 11 x86_64. I have a Pentium Dual Core E2180 running on an abit ab9 pro motherboard. The first core (CPU0) does not seem to scale ever.

# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Pentium(R) Dual CPU E2180 @ 2.00GHz
stepping : 13
cpu MHz : 1224.000
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm
bogomips : 4079.98
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Pentium(R) Dual CPU E2180 @ 2.00GHz
stepping : 13
cpu MHz : 1224.000
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm
bogomips : 4079.40
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

# cpufreq-info
cpufrequtils 005: 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
  hardware limits: 1.22 GHz - 2.04 GHz
  available frequency steps: 2.04 GHz, 1.63 GHz, 1.22 GHz
  available cpufreq governors: ondemand, userspace, performance
  current policy: frequency should be within 1.22 GHz and 1.22 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.22 GHz (asserted by call to hardware).
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which need to switch frequency at the same time: 1
  hardware limits: 1.22 GHz - 2.04 GHz
  available frequency steps: 2.04 GHz, 1.63 GHz, 1.22 GHz
  available cpufreq governors: ondemand, userspace, performance
  current policy: frequency should be within 1.22 GHz and 2.04 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.22 GHz (asserted by call to hardware).

This looks to be a bug in the acpi-cpufreq driver as I also see the same issue in Ubuntu (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/324211)

[Jay (jay-redhat-bugs)]

Created attachment 346232
jay's lscpi -vv output

[Jay (jay-redhat-bugs)]

Created attachment 346233
lspci -vvn output

[Jay (jay-redhat-bugs)]

Created attachment 346234
jay's lsmod output

[Jay (jay-redhat-bugs)]

Created attachment 346235
jay's dmidecode output

[Jay (jay-redhat-bugs)]

Created attachment 346236
jay's dmesg output

[Pépou (yannickw24)]

Having this exact same issue on a CoreDuo running 9.04. The cpu frequency is stocked at 1Ghz. The computer is so slow, very annoying bug.

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 9 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[kedmond (kedmond)]

I have a Intel Core 2 Duo T9500 in a Dell E6400 Latitude. I have the same problem. When I type "cpufreq-info" I get the following:

cpufrequtils 004: 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
  hardware limits: 800 MHz - 2.54 GHz
  available frequency steps: 2.54 GHz, 2.53 GHz, 1.60 GHz, 800 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 800 MHz and 800 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.
  cpufreq stats: 2.54 GHz:0.00%, 2.53 GHz:0.00%, 1.60 GHz:0.00%, 800 MHz:0.01% (1794)
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which need to switch frequency at the same time: 1
  hardware limits: 800 MHz - 2.54 GHz
  available frequency steps: 2.54 GHz, 2.53 GHz, 1.60 GHz, 800 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 800 MHz and 800 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.
  cpufreq stats: 2.54 GHz:0.00%, 2.53 GHz:0.00%, 1.60 GHz:0.00%, 800 MHz:0.01% (1842)

The problem lies in the fact that the governer only wants to adjust the speed between 800 and 800. It's broken. Fix it please.

[Bug (bug-redhat-bugs)]

Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

[everflux (tklaunchpad)]

Tested with Karmic dev version: Same problem here, Thinkpad T43 gets stuck to lowest CPU speed as soon as CPU temperature is at 55C. Gets back to 2Ghz when 50C is reached.
Verified with cpufreq-info. Does not happen on Thinkpad T60.

[heheman3000 (mizzao)]

I have this problem as well but surprisingly, only one of the cores exhibits it (core 0):

cpufrequtils 005: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to <email address hidden>, please.
analyzing CPU 0:
  driver: powernow-k8
  CPUs which need to switch frequency at the same time: 0
  hardware limits: 800 MHz - 3.20 GHz
  available frequency steps: 3.20 GHz, 2.50 GHz, 2.10 GHz, 800 MHz
  available cpufreq governors: userspace, ondemand, performance
  current policy: frequency should be within 800 MHz and 800 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.
analyzing CPU 1:
  driver: powernow-k8
  CPUs which need to switch frequency at the same time: 1
  hardware limits: 800 MHz - 3.20 GHz
  available frequency steps: 3.20 GHz, 2.50 GHz, 2.10 GHz, 800 MHz
  available cpufreq governors: userspace, ondemand, performance
  current policy: frequency should be within 800 MHz and 3.20 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.
analyzing CPU 2:
  driver: powernow-k8
  CPUs which need to switch frequency at the same time: 2
  hardware limits: 800 MHz - 3.20 GHz
  available frequency steps: 3.20 GHz, 2.50 GHz, 2.10 GHz, 800 MHz
  available cpufreq governors: userspace, ondemand, performance
  current policy: frequency should be within 800 MHz and 3.20 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.
analyzing CPU 3:
  driver: powernow-k8
  CPUs which need to switch frequency at the same time: 3
  hardware limits: 800 MHz - 3.20 GHz
  available frequency steps: 3.20 GHz, 2.50 GHz, 2.10 GHz, 800 MHz
  available cpufreq governors: userspace, ondemand, performance
  current policy: frequency should be within 800 MHz and 3.20 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.

[Rich (rincebrain)]

Holds for me on a fresh install of Karmic on a T61p.

[everflux (tklaunchpad)]

Check your bios settings - make sure you have set "maximum performance" for ac and battery power and _not_ "custom" or something like that. (That was a problem I had with a T60)
The bios will then "adjust" the maximum available speeds which are setable from the kernel.

[C. Brayton (cbrayton-boizebueditorial)]

Me, too, on a Latitude D620 with Duo 2 CPU (2GHz), running 9.10 Karmic (2.6.31-17-generic).

But with a twist.

After booting, cpufreq-info shows that all is well: the ondemand governor is managing steps between 1GHz and 2GHz, the machine is humming along, moving to higher or lower steps as needed.

But after a certain amount of time, something (acpi-cpufreq?) automatically changes those settings and I am stuck on the lowest setting on both CPU 0 and CPU 1:

política atual: a frequência deveria estar entre 1000 MHz e 1000 MHz. O governor "userspace" deve decidir qual velocidade usar dentro desse limite.

(My machine speaks Portuguese, but you can see that the interval is between 1GHz and 1GHz. I changed the governor to userspace in a bid to manually set freq to 2GHz with echo 2000000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
 or cpufreq-selector -f 2000000)

I have seen many similar complaints in the forums.

BIOS has no settings like the ones mentioned by everflux (note #23).

I have uninstalled all cpufreq demons (kpowersave, cpudyn, cpufreqd, powernowd).

Canonical Kernel Team, ride to the rescue!

[C. Brayton (cbrayton-boizebueditorial)]

PS: CPU temp is not reaching a threshold that would trigger this adjustment, I think.

[Brad Figg (brad-figg)]

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.