Bug 1085525

Summary:	/sys/devices/.../cpufreq/cpuinfo_cur_freq not readable by regular users
Product:	[Fedora] Fedora	Reporter:	Gene Czarcinski <gczarcinski>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mchehab
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1482056 (view as bug list)		Environment:
Last Closed:	2014-04-09 15:49:52 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Gene Czarcinski 2014-04-08 20:08:49 UTC

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

Comment 1 Gene Czarcinski 2014-04-08 20:10:02 UTC

*** Bug 1085014 has been marked as a duplicate of this bug. ***

Comment 2 Josh Boyer 2014-04-09 14:10:57 UTC

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.

Comment 3 Gene Czarcinski 2014-04-09 15:28:54 UTC

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.