Bug 1410755 - Linux and/or Intel pstate driver detects incorrect maximum CPU frequency (cpuinfo_max_freq) [NEEDINFO]
Summary: Linux and/or Intel pstate driver detects incorrect maximum CPU frequency (cpu...
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 25
Hardware: ia64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-06 11:25 UTC by Ben McCann
Modified: 2019-01-09 12:54 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-04-28 17:12:04 UTC
Type: Bug
jforbes: needinfo?


Attachments (Terms of Use)

Description Ben McCann 2017-01-06 11:25:23 UTC
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@vger.kernel.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.

Comment 1 Ben McCann 2017-01-10 11:53:38 UTC
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.

Comment 2 Laura Abbott 2017-01-17 01:22:22 UTC
*********** 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.

Comment 3 Ben McCann 2017-01-17 09:34:57 UTC
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

Comment 4 Justin M. Forbes 2017-04-11 14:52:50 UTC
*********** 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.

Comment 5 Justin M. Forbes 2017-04-28 17:12:04 UTC
*********** 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.

Comment 6 Ben McCann 2017-08-17 10:50:05 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.