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:
Created attachment 271951 [details] lspci -vv output
Created attachment 271961 [details] lspci -vvn output
Created attachment 271971 [details] dmidecode output
[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
Created attachment 274581 [details] dmesg output Here's my dmesg
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, 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%
(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
(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.
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.
Created attachment 298400 [details] dmesg with options acpi=debug cpufreq.debug=7
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.
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.
It looks like removing both the battery and AC connector had fixed the problem in my case.
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
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.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)
Created attachment 346232 [details] jay's lscpi -vv output
Created attachment 346233 [details] lspci -vvn output
Created attachment 346234 [details] jay's lsmod output
Created attachment 346235 [details] jay's dmidecode output
Created attachment 346236 [details] jay's dmesg output
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
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.