Hide Forgot
Created attachment 558917 [details] echo of /proc/cpuinfo and of various cpupower commands abd screenshots of i7z Description of problem: Frequency scaling does not work Version-Release number of selected component (if applicable): All kernels of F16 since I bought this laptop, Dell E6220 with Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz How reproducible: Always Steps to Reproduce: 1. cpupower frequency-info 2. cpupower frequency-set -u 800000 -g powersave 3. cpupower frequency-info Actual results: The frequency stays at its upper value (28010000) and it is never lowered to the value input by cpupower frequency-set, whichever governor is asked for. cpupower-info correctly reports that the allowed range is 800000-800000 but the current frequency stays at 2.8 GHz Expected results: The frequency should be lowered to 800 MHz Additional info: The problem exists for whichever frequency/governor combination is issued. The reported current frequency stays always at the highest frequency (2.8 GHz) The problem is specific of this cpu model/laptop, other laptops I own running F16 (x86_64) with different Intel i7 cpu's behave normally Also, despite the frequency is reported as the maximum one (2.8 GHz) by cpupower frequency-info despite the command to lower it to 800000, the current frequency reported by an Intel tool is neither 2.8 GHz nor 800 MHz but rather 2.1 GHz (see attached screenshots)!!! Attached you find: a) an ascii file with the result of several cpupower commands showing the problem b) a screenshot of the i7z utility when the frequency is et to maximum (2.8 GHz) c) a screenshot of the i7z utility when the frequency is set to 800 MHz but reported as 2.8 GHz by cpupower frequency-info
it looks like the transition is failing for some reason. Boot with cpufreq.debug=7 and run the cpupower frequency-set -u 800000 -g userspace command again. Just to rule out any interfering applications, do this from a console, without all the desktop stuff running. then attach the output of dmesg after it fails.
Created attachment 559102 [details] dmesg output as requested dmesg output when booting with cpufreq.debug=7 and issuing cpupower frequency-set commands
Hi thanks for the quick reply. I booted with cpufreq.debug=7 but I cannot see any message related to cpufreq in dmesg (see attachment) despite issuing several cpupower frequency-set commands. Maybe the kernel must be recompiled with some debugging enabled? Rather your suggestion of trying without a graphical environment was extremely helpful. Booting in single user mode -> then going to runlevel 3 results in a perfectly working cpu frequency scaling from console. Booting into graphical mode (up to the gdm screen) with nobody logged in still results in frequency scaling working perfectly from the console. Then I tried to investigate what is the problem with the graphical environment (xfce in my case). After lengthy trials I could determine that xfce4-cpugraph-plugin is the culprit. This plugin is a very simple piece of code showing how busy are the cpu's and nothing more. When I disable it, frequency scaling works also in the graphical environment, when I re-enable the plugin it stops working. So, you can safely redirect the bug to xfce4-cpugraph-plugin. Still if would be nice if you have any hint why such a simple code can interfere with frequency scaling on this particular cpu. I have other laptops/cpus (including another with a slightly different i7 model) where xfce4-cpugraph-pluging does not cause any problem to the frequency scaling. Also it would be interesting to know if/how one could activate the kernel debugging since apparently cpufreq.debug=7 did not work Thanks again
you might try lowering the frequency at which it updates.
... I am afraid I was wrong in attaching the blame to xfce4-cpugraph-plugin. Indeed removing that applet solved my (original) problem, however the same issue pops up with gkrellm. If gkrellm is on, cpu frequency scaling does no longer work anymore, exactly as it does for xfce4-cpugraph-plugin -> hence I suspect a much more general problem, maybe it is really a (kernel?) problem which shows up when an application is monitoring the cpu activity
Hi, I have to chime in with a "me too". Fedora 16 x86_64. Cpu is stuck on lowest frequency. I tried a few kernels I still have: [root@nepomuk cpufreq]# rpm -q kernel kernel-3.3.4-1.fc16.x86_64 kernel-3.3.4-3.fc16.x86_64 kernel-3.3.5-2.fc16.x86_64 but to no avail: [root@nepomuk cpufreq]# for i in *; do echo -n $i:; cat $i; done affected_cpus:0 bios_limit:2933000 cpuinfo_cur_freq:1600000 cpuinfo_max_freq:2933000 cpuinfo_min_freq:1600000 cpuinfo_transition_latency:10000 related_cpus:0 scaling_available_frequencies:2933000 2133000 1600000 scaling_available_governors:conservative userspace powersave ondemand performance scaling_cur_freq:1600000 scaling_driver:acpi-cpufreq scaling_governor:ondemand scaling_max_freq:1600000 scaling_min_freq:1600000 scaling_setspeed:<unsupported> Booting with 3.1.0.7 from an older Fedora 16 Live Desktop lets me switch frequencies. I guess this came with some kernel update. Klaus
Interestingly, the kernel on F17 on 32 bits seems to not have this problem. [root@acer cpu]# uname -r 3.3.4-5.fc17.i686 Klaus
anybody interested in this at all?
Sure, but as the maintainer of the xfce4-cpu-freq-plugin there is nothing I can do because I agree that the problem is not the plugin but somewhere deeper in the stack. Just to be clear about this: Do both of you have this problem and don't have the plugin installed or running?
From my side, I have to say that starting with kernel-3.3.2-6 (I could be wrong by one or two updates) things suddenly started to work on all my laptops. To me this proves that the problem was squarely in the kernel, however I did not see in the kernel changelog nothing which was even loosely related to this problem. In summary, with the latest F16 kernel releases I have CPU scaling working as expected with both xfce4-cpu-freq-plugin and gkrellm running, even though it seems to have been fixed more by chance than by intention.
Christoph, sorry, I was already under the impression that this was seen as a kernel problem. I was wrong of course. I'm still not seeing any difference on f16 with the current kernel (3.3.7). Probably I should open a new BZ and clearly mark it as a kernel thing....
I did a test on another HW. There scaling works. I do have two systems where I went back to the release kernel of F16, as there scaling does work. Sometime probably in April/May it stopped working on my main system
For me there is nothing I can do here. If you are still having problems, please reopen this bug and make sure it is assigned to the kernel and not to the 'kernel' component.