could somebody explain why do I need root credentials to read cpuinfo_cur_freq file? Why other files in the same directory have 444 and not 400 as the cpuinfo_cur_freq? What so special about the current cpu freq readings? $ lso /sys/devices/system/cpu/cpu?/cpufreq/cpuinfo* 400 -r-------- 1 root 4.0K Jan 24 09:30 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq 444 -r--r--r-- 1 root 4.0K Jan 24 09:37 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq 444 -r--r--r-- 1 root 4.0K Jan 24 09:37 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq 444 -r--r--r-- 1 root 4.0K Jan 24 09:37 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency 400 -r-------- 1 root 4.0K Jan 24 09:53 /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq 444 -r--r--r-- 1 root 4.0K Jan 24 09:53 /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq 444 -r--r--r-- 1 root 4.0K Jan 24 09:53 /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_min_freq 444 -r--r--r-- 1 root 4.0K Jan 24 09:53 /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_transition_latency
This one is a duplicate of bug 65611, and the rational is partially therein and particularly in the links within comment 6.
well, the problem is 12 years people are still confused why it is this way. Which makes me to believe that something is wrong with the design. Anyway, as far as I can read from scaling_cur_freq I'm fine.
*** This bug has been marked as a duplicate of bug 65611 ***