Description of problem: Fedora 25 with Linux 4.8.15-300.fc25.x86_64 doesn't detect the correct maximum frequency for my Intel Broadwell i7-6850k CPU. I have the maximum frequency set to 4.4 GHz in the Bios but Linux detects the maximum frequency as only 4.0 GHz. Windows 10, Debian Stable (with Linux 3.16), and Ubuntu 16.04 (with Linux 4.4) all detect the upper frequency correctly. See the actual/expected results for cpupower output. I've filed this as a low severity bug because the machine *works* but I'm loosing 10% of its performance. (Actually, I'm loosing 600 MHz because the pstate driver won't turbo past 3.8 GHz but that will be the subject of another bug someday). Version-Release number of selected component (if applicable): Fedora 25 / Linux 4.8.15-300.fc25.x86_64 How reproducible: 100% Steps to Reproduce: 1. Boot Fedora 25 / Linux 4.8.15-300.fc25.x86_64 on my PC. 2. Examine 'cpupower -frequency-info' or 'cat /sys/devices/system/cpu/*/cpufreq/cpuinfo_max_freq'. 3. Actual results: (Note the upper hardware limit is 4.00 instead of 4.40 GHz): sudo cpupower frequency-info analyzing CPU 0: driver: intel_pstate CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: Cannot determine or is not supported. hardware limits: 1.20 GHz - 4.00 GHz available cpufreq governors: performance powersave current policy: frequency should be within 1.20 GHz and 4.00 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency: 2.09 GHz (asserted by call to hardware) boost state support: Supported: yes Active: yes Expected results: (This is from Debian Stable with Linux 3.16 kernel. Ubuntu 16.04 was similar). cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq.org, please. analyzing CPU 0: driver: intel_pstate CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 0.97 ms. hardware limits: 1.20 GHz - 4.40 GHz available cpufreq governors: performance, powersave current policy: frequency should be within 1.20 GHz and 4.40 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency is 1.21 GHz. Additional info: I'm happy to help trouble-shoot this issue. Just LMK what to check or try.
I booted the Centos 7.3 installer and checked the /sys/devices/system/cpu/*/cpufreq/cpuinfo_max_freq setting from the installer's shell pseudo-TTY. The cpuinfo_max_freq was *correctly* reported on Centos 7.3 hence I believe the pstate driver would work correctly. Note, I didn't actually install Centos 7.3 to prove that assertion but the evidence in /sys/.../cpuinfo_max_freq is encouraging.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 25 kernel bugs. Fedora 25 has now been rebased to 4.9.3-200.fc25. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 26, and are still experiencing this issue, please change the version to Fedora 26. If you experience different issues, please open a new bug report for those.
No change in 4.9.3-200.fc25. Bug is still present as documented. Note the upper bound on the hardware frequency limits is 4.0 GHz when it should be 4.4 GHz *and* the actual upper bound is 3.8 GHz when the system is put under load: [04:28 bmccann ~]$ uname -a Linux canopus 4.9.3-200.fc25.x86_64 #1 SMP Fri Jan 13 01:01:13 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux [04:28 bmccann ~]$ sudo cpupower frequency-info analyzing CPU 0: driver: intel_pstate CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: Cannot determine or is not supported. hardware limits: 1.20 GHz - 4.00 GHz available cpufreq governors: performance powersave current policy: frequency should be within 1.20 GHz and 4.00 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency: 1.20 GHz (asserted by call to hardware) boost state support: Supported: yes Active: yes [04:29 bmccann ~]$ grep MHz /proc/cpuinfo cpu MHz : 1200.585 cpu MHz : 1200.585 cpu MHz : 1199.926 cpu MHz : 3799.951 <======== cpu MHz : 1200.585 cpu MHz : 1207.397 cpu MHz : 1200.146 cpu MHz : 1201.904 cpu MHz : 1200.146 cpu MHz : 3799.951 <======== cpu MHz : 1200.146 cpu MHz : 1202.783
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 25 kernel bugs. Fedora 25 has now been rebased to 4.10.9-200.fc25. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 26, and are still experiencing this issue, please change the version to Fedora 26. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
PROBLEM SOLVED... I hit the same issue with Manjaro (Arch) Linux and I fixed it on *that* distro. The same fix will probably work for Fedora/Redhat as well. The problem is that the CPU MSR register MSR_NHM_TURBO_RATIO_LIMIT register (0x1ad) reports different values when running under Ubuntu vs Manjaro (and presumably Redhat). The value reported under Manjaro doesn't correctly report the maximum clock ratios configured into the BIOS. As an experiment, I prevented Manjaro from loading the Intel CPU microcode during boot. (On manjaro, the microcode is loaded by grub as an 'initrd' image. I don't know how Redhat loads the microcode so you'll have to figure that out). That solved the problem! And, to double check, my Ubuntu installation does *not* have Intel microcode patches installed so the Ubuntu distro never tried to patch the microcode. This isn't a good long term fix because the Intel microcode likely patches subtle defects in the processor. I wouldn't recommend it for a permanent change but at least this analysis shows the problem isn't with the Linux kernel.