[Bug 198637] New: cpuinfo_cur_freq differs from scaling_cur_freq on an AMD FX-8320E

From: <hidden>
Date: 2018-02-01 17:17:43

https://bugzilla.kernel.org/show_bug.cgi?id=198637

            Bug ID: 198637
           Summary: cpuinfo_cur_freq differs from scaling_cur_freq on an
                    AMD FX-8320E
           Product: Power Management
           Version: 2.5
    Kernel Version: 4.15.0
          Hardware: x86-64
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: cpufreq
          Assignee: linux-pm@vger.kernel.org
          Reporter: stefantalpalaru@yahoo.com
        Regression: No

With the "performance" governor:

root# cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq
4400000
4400000
4400000
4400000
4400000
4400000
4400000
4400000
root# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq 
3029755
3114686
4173759
4365672
2865808
3887821
4247518
3671205

This is a problem because only the latter, wrong value is readable by non-root
users and it's also the only one shown in /proc/cpuinfo.

According to this 2011 email -
http://permalink.gmane.org/gmane.linux.kernel.cpufreq/7008 :
everyone may read out scaling_cur_freq, and scaling_cur_freq differs from
cpuinfo_cur_freq _only_ if something is broken

So what's broken and how can we fix it?

Additional info:
- scaling_driver is "acpi-cpufreq"
- scaling_min_freq and scaling_max_freq have correct values (same as their
cpuinfo_ counterparts)
- the CPU has Turbo Core disabled and it's overclocked to 4.4GHz but the
problem should also manifest on default setups

-- 
You are receiving this mail because:
You are the assignee for the bug.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help