Description of problem: On an AMD A10-7850K system, with current kernel 3.14.5-200, turbo boost is not active. cpupower frequency-info output: analyzing CPU 0: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 4.0 us. hardware limits: 1.70 GHz - 3.70 GHz available frequency steps: 3.70 GHz, 3.50 GHz, 3.00 GHz, 2.40 GHz, 1.70 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 1.70 GHz and 3.70 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.70 GHz (asserted by call to hardware). boost state support: Supported: yes Active: no Boost States: 3 Total States: 8 Pstate-Pb0: 4000MHz (boost state) Pstate-Pb1: 3900MHz (boost state) Pstate-Pb2: 3800MHz (boost state) Pstate-P0: 3700MHz Pstate-P1: 3500MHz Pstate-P2: 3000MHz Pstate-P3: 2400MHz Pstate-P4: 1700MHz Note the "Active: no" Checking with `turbostat` or `cpupower monitor` reveals that turbo boost is not working. Adding "nomodeset" to kernel startup parameters fixes this: I now get "Active: yes", and `turbostat` show turbo boot being used. Version-Release number of selected component (if applicable): 3.14.5-200 How reproducible: always Steps to Reproduce: 1. as root, run `cpupower frequency-info` Actual results: boost state support: Active: no Expected results: boost stat support should be active: yes.
The behavior changed with the most recent kernel update to 3.16.2-200: now "cpupower frequency-info" shows "Active: yes". (The rest of its output is unchanged). Turbo does not work though - in fact performance has gotten worse: according to "turbostat" its starts at 3700 MHz and quickly drops to 3500 MHz after about a minute (with one CPU bound thread and no thermal problems). With "nomodeset" on the kernel command line turbo, it starts out at 4 GHz and drops to 3800 MHz after some time.
*********** 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 20 kernel bugs. Fedora 20 has now been rebased to 3.17.2-200.fc20. 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 21, and are still experiencing this issue, please change the version to Fedora 21. If you experience different issues, please open a new bug report for those.
Kernel 3.17.2-200 shows the same behavior as 3.16.2 (my comment from 2014-09-15). As a test, I run a single bzip2 process to compress a largish tar file to /dev/null. With nomodeset, gnome-shell places a considerable load on the CPU, which might explain why turbo drops to about 3.8 GHz after some time. With default options, there is no CPU load except for the bzip2 process.
*********** 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 20 kernel bugs. Fedora 20 has now been rebased to 3.18.7-100.fc20. 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 21, and are still experiencing this issue, please change the version to Fedora 21. If you experience different issues, please open a new bug report for those.
With current Fedora 21 kernel, 3.18.7-200.fc21.x86_64, turbo is still disabled ("active: no").
*********** 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 21 kernel bugs. Fedora 21 has now been rebased to 3.19.5-200.fc21. 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 22, and are still experiencing this issue, please change the version to Fedora 22. If you experience different issues, please open a new bug report for those.
Fedora 22 with kernel 4.0.0-1.fc22.x86_64: I get Supported: yes and Active: no, regardless of whether I specify "nomodeset" or not.
*********** 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 22 kernel bugs. Fedora 22 has now been rebased to 4.2.3-200.fc22. 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 23, and are still experiencing this issue, please change the version to Fedora 23. If you experience different issues, please open a new bug report for those.
The problem is still there in Fedora 23 with kernel 4.2.3-300.fc23.x86_64.
*********** 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 23 kernel bugs. Fedora 23 has now been rebased to 4.7.4-100.fc23. 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 24 or 25, and are still experiencing this issue, please change the version to Fedora 24 or 25. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are 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 24 kernel bugs. Fedora 25 has now been rebased to 4.10.9-100.fc24. 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.
The issue did also occur in Fedora 25. The issue only shows up when the internal GPU is used. With a dedicated GPU installed, the CPU turbo works fine. I'm no longer able to check if the issue persists in newer kernel versions since I can't easily remove the GPU.
This is the same on RHEL 7.3 with a Hp Elitebook 745 G2 (AMD A10-7350B APU) Tuned enabled and set to balanced. # cpupower frequency-info analyzing CPU 0: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 4.0 us hardware limits: 1.10 GHz - 2.10 GHz available frequency steps: 2.10 GHz, 1.90 GHz, 1.60 GHz, 1.30 GHz, 1.10 GHz available cpufreq governors: conservative userspace powersave ondemand performance current policy: frequency should be within 1.10 GHz and 2.10 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency: 1.10 GHz (asserted by call to hardware) boost state support: Supported: yes Active: no Boost States: 0 Total States: 5 Pstate-P0: 3300MHz Pstate-P1: 2800MHz Pstate-P2: 2500MHz Pstate-P3: 2100MHz Pstate-P4: 1900MHz
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
same problem with Fedora 34 kernel-core-5.11.12-300.fc34.x86_64 sudo cpupower frequency-info analyzing CPU 0: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 4.0 us hardware limits: 1.70 GHz - 3.70 GHz available frequency steps: 3.70 GHz, 3.50 GHz, 3.00 GHz, 2.40 GHz, 1.70 GHz available cpufreq governors: conservative ondemand userspace powersave performance schedutil current policy: frequency should be within 1.70 GHz and 3.70 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency: 3.70 GHz (asserted by call to hardware) boost state support: Supported: yes Active: no Boost States: 3 Total States: 8 Pstate-Pb0: 4000MHz (boost state) Pstate-Pb1: 4000MHz (boost state) Pstate-Pb2: 4000MHz (boost state) Pstate-P0: 3700MHz Pstate-P1: 3500MHz Pstate-P2: 3000MHz Pstate-P3: 2400MHz Pstate-P4: 1700MHz