Public bug reported:
OS: Kubuntu 24.04.3 LTS
Hardware: Clevo PD5x_7xSNC_SND_SNE, Intel i9-14900HX CPU, BIOS version
1.07.17SMIN29
Steps to reproduce:
1. Run `sudo apt install
linux-{image,modules,modules-extra,headers,tools}-6.14.0-29-generic`.
2. Boot into the newly installed kernel.
3. Run `echo 0 | sudo tee /sys/device/system/cpu/intel_pstate/no_turbo`.
4. Run `sudo dmesg`.
Expected result: The `echo | sudo tee` command should successfully run.
`sudo dmesg` should have messages unrelated to intel_pstate displayed at
the very end of the log. System performance should be normal. (Note that
it is normal to see some "Turbo disabled by BIOS" messages earlier on in
the dmesg log, but they stop after a while and turbo boost ends up
available.)
Actual result: The `echo | sudo tee` command errors out. `sudo dmesg`
shows `intel_pstate: Turbo disabled by BIOS or unavailable on processor`
at the very end of the log. System performance is dramatically reduced.
Additional information:
I spent the last couple of days bisecting the Ubuntu kernel. I found
that at the tag `Ubuntu-hwe-6.14-6.14.0-15.15_24.04.1`, turbo boost
worked, while at the tag `Ubuntu-hwe-6.14-6.14.0-24.24_24.04.1`, turbo
boost was broken as described above. Bisecting between them, the first
bad commit ended up being:
commit 32ac7dd0d507321d19f9ad9d9e81d031635365d7
Author: Srinivas Pandruvada <[email protected]>
Date: Tue Apr 29 14:07:11 2025 -0700
cpufreq: intel_pstate: Unchecked MSR aceess in legacy mode
BugLink: https://bugs.launchpad.net/bugs/2113881
commit ac4e04d9e378f5aa826c2406ad7871ae1b6a6fb9 upstream.
When turbo mode is unavailable on a Skylake-X system, executing the
command:
# echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo
results in an unchecked MSR access error:
WRMSR to 0x199 (attempted to write 0x0000000100001300).
This issue was reproduced on an OEM (Original Equipment Manufacturer)
system and is not a common problem across all Skylake-X systems.
This error occurs because the MSR 0x199 Turbo Engage Bit (bit 32) is set
when turbo mode is disabled. The issue arises when intel_pstate fails to
detect that turbo mode is disabled. Here intel_pstate relies on
MSR_IA32_MISC_ENABLE bit 38 to determine the status of turbo mode.
However, on this system, bit 38 is not set even when turbo mode is
disabled.
According to the Intel Software Developer's Manual (SDM), the BIOS sets
this bit during platform initialization to enable or disable
opportunistic processor performance operations. Logically, this bit
should be set in such cases. However, the SDM also specifies that "OS
and applications must use CPUID leaf 06H to detect processors with
opportunistic processor performance operations enabled."
Therefore, in addition to checking MSR_IA32_MISC_ENABLE bit 38, verify
that CPUID.06H:EAX[1] is 0 to accurately determine if turbo mode is
disabled.
Fixes: 4521e1a0ce17 ("cpufreq: intel_pstate: Reflect current no_turbo
state correctly")
Signed-off-by: Srinivas Pandruvada <[email protected]>
Cc: All applicable <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Manuel Diewald <[email protected]>
Signed-off-by: Mehmet Basaran <[email protected]>
drivers/cpufreq/intel_pstate.c | 3 +++
1 file changed, 3 insertions(+)
This is a simple three-line commit:
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 9c4cc01fd51a..43e847e9f741 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -598,6 +598,9 @@ static bool turbo_is_disabled(void)
{
u64 misc_en;
+ if (!cpu_feature_enabled(X86_FEATURE_IDA))
+ return true;
+
rdmsrl(MSR_IA32_MISC_ENABLE, misc_en);
return !!(misc_en & MSR_IA32_MISC_ENABLE_TURBO_DISABLE);
It does not appear I am the only individual seeing these symptoms - a
user using Arch Linux seems to have experienced this same issue:
https://bbs.archlinux.org/viewtopic.php?id=305564 A Gentoo user seems to
have run into the same thing:
https://forums.gentoo.org/viewtopic-p-8866128.html?sid=e97619cff0d9c79c2eea2cfe8f60b0d3
While it's unclear what hardware the Gentoo user is using, the Arch
Linux user seems to be using a very similar machine as to what I'm using
(Clevo-based machine with an 19-14900HX).
I'm fairly certain this is the firmware's fault, since even when things
work, turbo starts out disabled and only ends up enabled later. This
seems to be what the Arch Linux user believes as well. That being said,
this did used to work acceptably well; maybe a hardware-specific quirk
could be added to skip this check on this particular model of Clevo
machine?
** Affects: linux-hwe-6.14 (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-hwe-6.14 in Ubuntu.
https://bugs.launchpad.net/bugs/2122531
Title:
Turbo boost stuck disabled on Clevo PD5x_7xSNC_SND_SNE
Status in linux-hwe-6.14 package in Ubuntu:
New
Bug description:
OS: Kubuntu 24.04.3 LTS
Hardware: Clevo PD5x_7xSNC_SND_SNE, Intel i9-14900HX CPU, BIOS version
1.07.17SMIN29
Steps to reproduce:
1. Run `sudo apt install
linux-{image,modules,modules-extra,headers,tools}-6.14.0-29-generic`.
2. Boot into the newly installed kernel.
3. Run `echo 0 | sudo tee /sys/device/system/cpu/intel_pstate/no_turbo`.
4. Run `sudo dmesg`.
Expected result: The `echo | sudo tee` command should successfully
run. `sudo dmesg` should have messages unrelated to intel_pstate
displayed at the very end of the log. System performance should be
normal. (Note that it is normal to see some "Turbo disabled by BIOS"
messages earlier on in the dmesg log, but they stop after a while and
turbo boost ends up available.)
Actual result: The `echo | sudo tee` command errors out. `sudo dmesg`
shows `intel_pstate: Turbo disabled by BIOS or unavailable on
processor` at the very end of the log. System performance is
dramatically reduced.
Additional information:
I spent the last couple of days bisecting the Ubuntu kernel. I found
that at the tag `Ubuntu-hwe-6.14-6.14.0-15.15_24.04.1`, turbo boost
worked, while at the tag `Ubuntu-hwe-6.14-6.14.0-24.24_24.04.1`, turbo
boost was broken as described above. Bisecting between them, the first
bad commit ended up being:
commit 32ac7dd0d507321d19f9ad9d9e81d031635365d7
Author: Srinivas Pandruvada <[email protected]>
Date: Tue Apr 29 14:07:11 2025 -0700
cpufreq: intel_pstate: Unchecked MSR aceess in legacy mode
BugLink: https://bugs.launchpad.net/bugs/2113881
commit ac4e04d9e378f5aa826c2406ad7871ae1b6a6fb9 upstream.
When turbo mode is unavailable on a Skylake-X system, executing the
command:
# echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo
results in an unchecked MSR access error:
WRMSR to 0x199 (attempted to write 0x0000000100001300).
This issue was reproduced on an OEM (Original Equipment Manufacturer)
system and is not a common problem across all Skylake-X systems.
This error occurs because the MSR 0x199 Turbo Engage Bit (bit 32) is
set
when turbo mode is disabled. The issue arises when intel_pstate fails
to
detect that turbo mode is disabled. Here intel_pstate relies on
MSR_IA32_MISC_ENABLE bit 38 to determine the status of turbo mode.
However, on this system, bit 38 is not set even when turbo mode is
disabled.
According to the Intel Software Developer's Manual (SDM), the BIOS
sets
this bit during platform initialization to enable or disable
opportunistic processor performance operations. Logically, this bit
should be set in such cases. However, the SDM also specifies that "OS
and applications must use CPUID leaf 06H to detect processors with
opportunistic processor performance operations enabled."
Therefore, in addition to checking MSR_IA32_MISC_ENABLE bit 38, verify
that CPUID.06H:EAX[1] is 0 to accurately determine if turbo mode is
disabled.
Fixes: 4521e1a0ce17 ("cpufreq: intel_pstate: Reflect current no_turbo
state correctly")
Signed-off-by: Srinivas Pandruvada
<[email protected]>
Cc: All applicable <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Manuel Diewald <[email protected]>
Signed-off-by: Mehmet Basaran <[email protected]>
drivers/cpufreq/intel_pstate.c | 3 +++
1 file changed, 3 insertions(+)
This is a simple three-line commit:
diff --git a/drivers/cpufreq/intel_pstate.c
b/drivers/cpufreq/intel_pstate.c
index 9c4cc01fd51a..43e847e9f741 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -598,6 +598,9 @@ static bool turbo_is_disabled(void)
{
u64 misc_en;
+ if (!cpu_feature_enabled(X86_FEATURE_IDA))
+ return true;
+
rdmsrl(MSR_IA32_MISC_ENABLE, misc_en);
return !!(misc_en & MSR_IA32_MISC_ENABLE_TURBO_DISABLE);
It does not appear I am the only individual seeing these symptoms - a
user using Arch Linux seems to have experienced this same issue:
https://bbs.archlinux.org/viewtopic.php?id=305564 A Gentoo user seems
to have run into the same thing:
https://forums.gentoo.org/viewtopic-p-8866128.html?sid=e97619cff0d9c79c2eea2cfe8f60b0d3
While it's unclear what hardware the Gentoo user is using, the Arch
Linux user seems to be using a very similar machine as to what I'm
using (Clevo-based machine with an 19-14900HX).
I'm fairly certain this is the firmware's fault, since even when
things work, turbo starts out disabled and only ends up enabled later.
This seems to be what the Arch Linux user believes as well. That being
said, this did used to work acceptably well; maybe a hardware-specific
quirk could be added to skip this check on this particular model of
Clevo machine?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-hwe-6.14/+bug/2122531/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
