Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: gkrellm-freq (and I believe xfce4-cpufreq-plugin) use /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq to obtain the current frequencies being used. This is done in user-space and does not require superuser access. There is also /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq which can be used to obtain this info BUT it DOES require superuser access. If the processor in the system is a more modern one from Intel such as the Haswell i5-4770S or the i7-4770, then /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq is NOT created and monitors such as gkrellm-freq do not work. See https://bugzilla.novell.com/show_bug.cgi?id=853140 Version-Release number of selected component (if applicable): Fedora 20, kernel-3.13.8-200.fc20.x86_64 How reproducible: everytime I can understand the reasoning for making access to cpuinfo_cur_freq restricted to superuser but it does seem to me to be more than a bit overly paranoid. Suggestion: add code to have scaling_cur_freq created OR make access to cpuinfo_cur_freq 444
*** Bug 1085014 has been marked as a duplicate of this bug. ***
The intel_pstate driver doesn't create that file. The novell bug you point to was closed as WONTFIX because the kernel is working as expected. You could follow the suggestion there and use cpupower to get the frequency info, or you could email the upstream intel_pstate author about whether or not it's possible to add the file you're looking for. Closing as UPSTREAM as this needs to be handled upstream.
I intend to turn in a bug report upstream after I have done some additional research. While things may be working as designed for power/frequency management on the new Intel processors, the kernel implementation breaks some code ... specifically gkrellm-freq (gkrellm-gkfrew) and xfce4-cpufreq-plugin. Both of these are user-space programs and to is not practical to use cpupower to get the frequesncies. In any case, because of the user-space (versus superuser) requirement, cpupower will NOT provide the necessary info. Try running the following as bot a regular user and as a superuser: cpupower -c all frequency-info and you will not that the current frequency is only provided when running as a superuser. Yes, ths impact of this missing functionality is small but I find it useful. I do not normally work in the kernel and it is taking me some effort to figure out the needed patch to cause intel_pstate to create scaling_cur_freq in addition to cpuinfo_cur_freq.