Description of problem: since probably at least kernel-3.3.1-5.fc16.x86_64 the cpufreq subsystem can't scale the cpufrequency on any other frequency than the lowest. cpupower reports: current policy: frequency should be within 1.60 GHz and 1.60 GHz. The governor "ondemand" may decide which speed to use within this range. Version-Release number of selected component (if applicable): Kernels greater than 3.3.1-5 (at least) How reproducible: Boot any kernel, check cpupower frequency-info Steps to Reproduce: 1. see above 2. 3. Actual results: See above Expected results: System will be able to scale frequencies Additional info: Am now running 3.1.0-7.fc16.x86_64 from Fed16 install media, as this is the only kernel I could still lay my hands on that still scales frequency Smolt ID 5b8b26fb-f7c1-4a20-a773-24946944ac4c
What CPU do you have? I am seeing: current policy: frequency should be within 800 MHz and 2.80 GHz. The governor "ondemand" may decide which speed to use within this range. So this is limited to certain systems or CPUs I would guess.
I have a model name : Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz This scales at available frequency steps: 2.93 GHz, 2.13 GHz, 1.60 GHz with 3.1.0-7.fc16.x86_64, but not with any kernel since May
This sounds very much like a bad memory stick. possible to run memtest and rule that out?
A bad memory? How would that possible that a bad memory dimm prevents the cpu to frequency scale on kernels >(=) 3.3.0, but scales well on 3.1? BTW, there are two machines showing the same behaviour. As I'm only able to activate acpi-cpufreq, I'd more lean to changes in acpi. But if you think it's the memory, I'll will run memtest, no prolem
Just to be no spoiler, I ran memtest. No problems, as expected
Could you please attach the output of dmesg from both the 3.1.0-7 and most recent 3.4 F16 kernel while also adding cpufreq.debug=7 to the command line?
Hi, attached you will find dmesg output and also cpupower frequency-info (the first one is in german, sorry) Klaus
Created attachment 610110 [details] output of respective dmesg and cpupower frequency-info
# Mass update to all open bugs. Kernel 3.6.2-1.fc16 has just been pushed to updates. This update is a significant rebase from the previous version. Please retest with this kernel, and let us know if your problem has been fixed. In the event that you have upgraded to a newer release and the bug you reported is still present, please change the version field to the newest release you have encountered the issue with. Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered. If you are not the original bug reporter and you still experience this bug, please file a new report, as it is possible that you may be seeing a different problem. (Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient).
Well, actually, no cigar. I'm sorry, but maybe the acpi of this motherboard just is too strange: With 3.6.2-1: analyzing CPU 0: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 10.0 us. hardware limits: 1.60 GHz - 2.93 GHz available frequency steps: 2.93 GHz, 2.13 GHz, 1.60 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 1.60 GHz and 1.60 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 1.60 GHz (asserted by call to hardware). boost state support: Supported: no Active: no Notice, it does recognize the higher frequencies, but neither performance, userspace nor ondemand has any different output than that shown in current policy. I'm back on 3.1.0-7.fc16, which has: analyzing CPU 0: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 10.0 us. hardware limits: 1.60 GHz - 2.93 GHz available frequency steps: 2.93 GHz, 2.13 GHz, 1.60 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 1.60 GHz and 2.93 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.60 GHz (asserted by call to hardware). boost state support: Supported: no Active: no
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. 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 '16'. 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 16'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 16 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, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. 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 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 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.