Bug 403651 - frequency scaling stuck at lowest speed
frequency scaling stuck at lowest speed
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-28 18:47 EST by Ryan Campbell
Modified: 2009-07-14 11:40 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 511840 (view as bug list)
Environment:
Last Closed: 2009-07-14 11:40:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
lspci -vv output (21.89 KB, application/octet-stream)
2007-11-28 18:48 EST, Ryan Campbell
no flags Details
lspci -vvn output (19.87 KB, application/octet-stream)
2007-11-28 18:49 EST, Ryan Campbell
no flags Details
dmidecode output (9.19 KB, application/octet-stream)
2007-11-28 18:50 EST, Ryan Campbell
no flags Details
dmesg output (30.07 KB, application/octet-stream)
2007-11-30 19:48 EST, Ryan Campbell
no flags Details
dmesg output of booting with cpufreq.debug=7 option (23.98 KB, text/plain)
2007-12-17 14:57 EST, Jaakko R
no flags Details
dmesg with options acpi=debug cpufreq.debug=7 (38.11 KB, text/plain)
2008-03-18 10:42 EDT, Łukasz Lis
no flags Details
jay's lscpi -vv output (30.48 KB, application/octet-stream)
2009-06-02 07:30 EDT, Jay Modi
no flags Details
lspci -vvn output (24.02 KB, application/octet-stream)
2009-06-02 07:31 EDT, Jay Modi
no flags Details
jay's lsmod output (1.74 KB, application/octet-stream)
2009-06-02 07:32 EDT, Jay Modi
no flags Details
jay's dmidecode output (11.43 KB, application/octet-stream)
2009-06-02 07:32 EDT, Jay Modi
no flags Details
jay's dmesg output (40.66 KB, application/octet-stream)
2009-06-02 07:33 EDT, Jay Modi
no flags Details

  None (edit)
Description Ryan Campbell 2007-11-28 18:47:15 EST
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:
Comment 1 Ryan Campbell 2007-11-28 18:48:38 EST
Created attachment 271951 [details]
lspci -vv output
Comment 2 Ryan Campbell 2007-11-28 18:49:31 EST
Created attachment 271961 [details]
lspci -vvn output
Comment 3 Ryan Campbell 2007-11-28 18:50:05 EST
Created attachment 271971 [details]
dmidecode output
Comment 4 Ryan Campbell 2007-11-28 18:57:42 EST
[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
Comment 5 Ryan Campbell 2007-11-30 19:48:49 EST
Created attachment 274581 [details]
dmesg output

Here's my dmesg
Comment 6 Jaakko R 2007-12-10 15:54:09 EST
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 linux@brodo.de, 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%
Comment 7 Chuck Ebbert 2007-12-10 16:59:41 EST
(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
Comment 8 Ryan Campbell 2007-12-10 17:34:35 EST
(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.
Comment 9 Jaakko R 2007-12-17 14:57:32 EST
Created attachment 289802 [details]
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.
Comment 10 Łukasz Lis 2008-03-18 10:42:37 EDT
Created attachment 298400 [details]
dmesg with options acpi=debug cpufreq.debug=7
Comment 11 Łukasz Lis 2008-03-18 10:46:11 EDT
Comment on attachment 298400 [details]
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.
Comment 12 Jaakko R 2008-03-18 15:55:51 EDT
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.
Comment 13 Łukasz Lis 2008-03-21 11:47:58 EDT
It looks like removing both the battery and AC connector had fixed the problem
in my case.
Comment 14 Bug Zapper 2008-05-14 00:03:21 EDT
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
Comment 15 Jay Modi 2009-06-02 06:53:43 EDT
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 cpufreq@vger.kernel.org, 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)
Comment 16 Jay Modi 2009-06-02 07:30:57 EDT
Created attachment 346232 [details]
jay's lscpi -vv output
Comment 17 Jay Modi 2009-06-02 07:31:40 EDT
Created attachment 346233 [details]
lspci -vvn output
Comment 18 Jay Modi 2009-06-02 07:32:06 EDT
Created attachment 346234 [details]
jay's lsmod output
Comment 19 Jay Modi 2009-06-02 07:32:51 EDT
Created attachment 346235 [details]
jay's dmidecode output
Comment 20 Jay Modi 2009-06-02 07:33:17 EDT
Created attachment 346236 [details]
jay's dmesg output
Comment 21 Bug Zapper 2009-06-09 19:14:30 EDT
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
Comment 22 Bug Zapper 2009-07-14 11:40:09 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.