[SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

haigioli · 2025-08-14 03:07:37

After months of follow-ups with Intel and various communities online, I've discovered that no_turbo is turned on and cannot be turned off when using any kernel and firmware past certain versions. Specifically:

linux-6.12.21-1 (lts included)

linux-firmware-20250311

This started for me on my i9-14900HX cpu. I have another thread on Newbie Corner that I marked as solved, but only with a temporary band-aid solution. The cpu is still nerfed beyond acceptable levels to this day.

Any combination of the kernel above 6.12.21 and any firmware version above 20250311 results in a severely throttled cpu (base clock frequency). Even kernel-6.12.41 (lts or otherwise) breaks turbo. As I documented in my original post, kernels/firmware combos after the above mentioned versions are reporting turbo either turned off in BIOS (it's not), or not a present feature on the CPU (it is).

I don't know how to report this bug and I certainly no longer know how to follow up on this issue. Clearly, turbo CAN and DOES work, but something changed in the kernel and firmware that's not reading this feature on certain intel CPUs.

How do I proceed?

Last edited by haigioli (2025-09-10 16:33:55)

mmy8x · 2025-08-14 05:04:03

Are you saying that 6.12.22 breaks turbo? There were practically no changes between .21 and .22. I can't see how any of that could be relevant:

55767d6e74ef (tag: v6.12.22) Linux 6.12.22
9e6e83e1e2d0 bcachefs: bch2_ioctl_subvolume_destroy() fixes
a964484a3537 serial: 8250_dma: terminate correct DMA in tx_dma_flush()
5f9176f82ec7 serial: stm32: do not deassert RS485 RTS GPIO prematurely
f86907583000 perf tools: Fix up some comments and code to properly use the event_source bus
b094e8e3988e memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove
a4931d9fb99e usb: xhci: Apply the link chain quirk on NEC isoc endpoints
6af20ac254cb usb: xhci: Don't skip on Stopped - Length Invalid
ed5760db3d8a net: usb: usbnet: restore usb%d name exception for local mac addresses
52e05bea53c2 net: usb: qmi_wwan: add Telit Cinterion FE990B composition
666e78b47713 net: usb: qmi_wwan: add Telit Cinterion FN990B composition
53a005d3019f tty: serial: fsl_lpuart: disable transmitter before changing RS485 related registers
27bd86d139ce tty: serial: 8250: Add Brainboxes XC devices
54f9a8dcab90 tty: serial: 8250: Add some more device IDs
0fac51a2d143 counter: microchip-tcb-capture: Fix undefined counter channel state on probe
181a2ab650f7 counter: stm32-lptimer-cnt: fix error handling when enabling
3ed38d0297fa ALSA: hda/realtek: Support mute LED on HP Laptop 15s-du3xxx
2bb139e483f8 netfilter: socket: Lookup orig tuple for IPv6 SNAT
2c1674fb52b2 drm/amd/display: Don't write DP_MSTM_CTRL after LT
95407304253a nfsd: fix legacy client tracking initialization
09691f367df4 atm: Fix NULL pointer dereference
dddd13f7f167 HID: hid-plantronics: Add mic mute mapping and generalize quirks
a532e7680878 ALSA: usb-audio: Add quirk for Plantronics headsets to fix control names
3423cae69078 (tag: v6.12.21) Linux 6.12.21

Although there may have been some change in Arch kernel package configuration.

Last edited by mmy8x (2025-08-14 05:07:07)

seth · 2025-08-14 06:44:14

I'd first and foremost isolate whether the kernel or firmware is the critical bit (ie. run the newer kernel w/ the older firmware and the newer firmware w/ the older kernel - though one would rather expect the ucode to be relevant)
Do you do anything about https://wiki.archlinux.org/title/Improv … rmance#CPU and notably https://wiki.archlinux.org/title/Improv … itigations ?

haigioli · 2025-08-14 10:53:41

@seth, I've done such a test. The ucode seems irrelevant here, as I'm running the current version. The problems begin when I change either the firmware or the kernel. I've run the firmware with the new kernel, as well as the old kernel with the new firmware (several versions, actually).

As for the scaling driver, no_turbo is only present when using intel_pstate, not acpi_cpufreq. I've spent a great deal of time performing almost all (in not all) option combinations with both drivers independently. Also, I have other intel laptops with arch on them to compare experiences to. This is unique to a handful of intel CPUs (i9-14900HX, in my case).

The mitigations thing is not something that occurred to me, when clearly, intel_pstate driver was working in passive and active modes in kernel 6.12.21. I'm currently using linux-lts-6.12.21. @mmy8x I don't know about 6.12.22, but I know .3x onward don't work. To be sure, I'll try the rest of the .2x series and see if any of them break.

Meanwhile, I'll gladly post outputs of whatever you folks would like to see from my system, if it helps.

Last edited by haigioli (2025-08-14 11:59:34)

mmy8x · 2025-08-14 11:12:43

haigioli wrote:

I don't know about 6.12.22, but I know .3x onward don't work. To be sure, I'll try the rest of the .2x series and see if any of them break.
Meanwhile, I'll gladly posst outputs of whatever you folks would like to see from my system, if it helps.

Nailing down the exact kernel release which broke it seems like the most sensible thing to do now, it will make it easier to find the offending change.

No need to try all 6.12.2x versions, just pick one in the middle before the last good version and the first bad version. Check if this version is good or bad, then repeat.

haigioli · 2025-08-14 13:11:03

The exact kernel where things break on turbo activation is

linux-6.12.28-1-lts

Again, I've got the latest firmware, but I stayed on linux-firmware-20250311, since it seems the most stable for me, since the firmware split into several packages, recently. Otherwise, turbo breaks.

I should mention that on this system, even when turbo works, the system never boots with no_turbo set to 0 (which is 'on'; the parameter is 'no_turbo', after all - I had to mention that, to be safe). So, I'm wondering if on some CPUs and some BIOSes, GRUB or whatever bootloader is reading the turbo capability late in the boot process and if perhaps Intel made a tweak that never gives a chance for turbo to be recognized later on.

As an example, some of the kernels after 6.12.21-1, sometimes the system boots and turbo can't be manually turned on until a second attempt, as in:

echo 0 | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo

It may first say, 'Operation not permitted.' And then, on second attempt onward, it works. I feel these are all hints. Does something about the firmware and driver get stricter as the versions wore on? Is it something in acpi boot process that's interfering with CPU capabilities being switched on?

On the occasion where I get 'Operation not permitted', invariably journalctl shows this:

journalctl -b 0 | grep -i turbo

kernel: intel_pstate: Turbo disabled by BIOS or unavailable on processor

On kernels 6.12.22 to .27, when/if this happens, an attempt at changing the no_turbo parameter stirs something and then it works. The above message appears during boot and if present, whenever I'm attempting to switch turbo on and I get 'Operation not permitted.'

seth · 2025-08-14 13:29:10

Most obvious contender is https://git.kernel.org/pub/scm/linux/ke … 005b574297
Can you compile a recent kernel w/ that patch reverted?

mmy8x · 2025-08-14 13:34:37

Three commits touch cpufreq between 6.12.27 and 6.12.28. The intel_pstate one explicitly monkeys with turbo support.

962d88304c3c cpufreq: Fix setting policy limits when frequency tables are used
573b04722907 cpufreq: Avoid using inconsistent policy->min and policy->max
d31806f14cc1 cpufreq: intel_pstate: Unchecked MSR aceess in legacy mode

https://lkml.org/lkml/2025/4/29/1671

Can you build a kernel with this change reverted?

Last edited by mmy8x (2025-08-14 13:36:18)

seth · 2025-08-14 13:40:36

Also check

lscpu | grep -i ida

haigioli · 2025-08-14 13:49:59

This is all very interesting. I knew there had to be something like this going on.

First of all, lscpu | grep -i ida produced no output.

Secondly, I don't know how to build a kernel with this change reverted. I do a lot of programming, so I'm not afraid to dive in, but I'll need direction.

seth · 2025-08-14 13:52:06

First of all, lscpu | grep -i ida produced no output.

Then it's https://git.kernel.org/pub/scm/linux/ke … 005b574297 for sure.
https://en.wikipedia.org/wiki/Intel_Dyn … celeration

Is the grep also empty on older kernels?

Edit: probably post the entire "lscpu" output

Last edited by seth (2025-08-14 13:57:21)

haigioli · 2025-08-14 14:04:33

The grep is indeed empty on the older kernels, as well.

As requested:

Architecture:                         x86_64
CPU op-mode(s):                       32-bit, 64-bit
Address sizes:                        39 bits physical, 48 bits virtual
Byte Order:                           Little Endian
CPU(s):                               32
On-line CPU(s) list:                  0-31
Vendor ID:                            GenuineIntel
Model name:                           Intel(R) Core(TM) i9-14900HX
CPU family:                           6
Model:                                183
Thread(s) per core:                   2
Core(s) per socket:                   24
Socket(s):                            1
Stepping:                             1
CPU(s) scaling MHz:                   18%
CPU max MHz:                          5800.0000
CPU min MHz:                          800.0000
BogoMIPS:                             4840.00
Flags:                                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect user_shstk avx_vnni dtherm arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req hfi vnmi umip pku ospke waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b fsrm md_clear serialize arch_lbr ibt flush_l1d arch_capabilities
Virtualization:                       VT-x
L1d cache:                            896 KiB (24 instances)
L1i cache:                            1.3 MiB (24 instances)
L2 cache:                             32 MiB (12 instances)
L3 cache:                             36 MiB (1 instance)
NUMA node(s):                         1
NUMA node0 CPU(s):                    0-31
Vulnerability Gather data sampling:   Not affected
Vulnerability Itlb multihit:          Not affected
Vulnerability L1tf:                   Not affected
Vulnerability Mds:                    Not affected
Vulnerability Meltdown:               Not affected
Vulnerability Mmio stale data:        Not affected
Vulnerability Reg file data sampling: Mitigation; Clear Register File
Vulnerability Retbleed:               Not affected
Vulnerability Spec rstack overflow:   Not affected
Vulnerability Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:             Mitigation; Enhanced / Automatic IBRS; IBPB conditional; PBRSB-eIBRS SW sequence; BHI BHI_DIS_S
Vulnerability Srbds:                  Not affected
Vulnerability Tsx async abort:        Not affected

This is on a working kernel: linux-6.12.27-1-lts

Last edited by haigioli (2025-08-14 14:12:40)

haigioli · 2025-08-14 14:19:12

Given the date on the patch you referred to, it adds up. Early May is when this problem began, for me.

seth · 2025-08-14 14:32:43

It's beyond adding up - the patch specifically tests for that flag…
https://en.wikipedia.org/wiki/List_of_I … HX_Refresh

The only question is whether the bug is that commit or the fact that X86_FEATURE_IDA was never set on your CPU.

haigioli · 2025-08-14 18:20:20

@seth, that's unsettlingly great. Now, what do I do? I don't know how to proceed. Any guidance would be appreciated. I feel we're close to a viable solution because of what you guys have answered on this thread, so far.

Also, I think that both might be true. I mean, why would no_turbo's native state on this CPU be set to 1 even when I can manually set turbo on? Something was always up with this.

Last edited by haigioli (2025-08-14 18:27:47)

seth · 2025-08-14 18:43:46

Google found https://openbenchmarking.org/s/Intel+Core+i9-14900HX and https://www.reddit.com/r/tuxedocomputer … s_15_slim/ which both list ida support (and I didn't find a lscpu output that doesn't)
Edit: also https://linux-hardware.org/?probe=7c3c9442dd&log=lscpu

Might be a resolution ("a" being the operative term here…) of the raptorlake disaster and gets constrained either by the BIOS or the microcode.
You could test to boot the system w/o https://archlinux.org/packages/extra/any/intel-ucode/ ONLY for the purpose to check whether that has impact on the lscpu output.

Last edited by seth (2025-08-14 18:44:17)

haigioli · 2025-08-14 19:00:14

I removed intel-ucode, restarted the system after a full shutdown, and here's the lscpu:

Architecture:                         x86_64
CPU op-mode(s):                       32-bit, 64-bit
Address sizes:                        39 bits physical, 48 bits virtual
Byte Order:                           Little Endian
CPU(s):                               32
On-line CPU(s) list:                  0-31
Vendor ID:                            GenuineIntel
Model name:                           Intel(R) Core(TM) i9-14900HX
CPU family:                           6
Model:                                183
Thread(s) per core:                   2
Core(s) per socket:                   24
Socket(s):                            1
Stepping:                             1
CPU(s) scaling MHz:                   43%
CPU max MHz:                          2200.0000
CPU min MHz:                          800.0000
BogoMIPS:                             4840.00
Flags:                                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect user_shstk avx_vnni dtherm arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req hfi vnmi umip pku ospke waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b fsrm md_clear serialize arch_lbr ibt flush_l1d arch_capabilities
Virtualization:                       VT-x
L1d cache:                            896 KiB (24 instances)
L1i cache:                            1.3 MiB (24 instances)
L2 cache:                             32 MiB (12 instances)
L3 cache:                             36 MiB (1 instance)
NUMA node(s):                         1
NUMA node0 CPU(s):                    0-31
Vulnerability Gather data sampling:   Not affected
Vulnerability Itlb multihit:          Not affected
Vulnerability L1tf:                   Not affected
Vulnerability Mds:                    Not affected
Vulnerability Meltdown:               Not affected
Vulnerability Mmio stale data:        Not affected
Vulnerability Reg file data sampling: Vulnerable: No microcode
Vulnerability Retbleed:               Not affected
Vulnerability Spec rstack overflow:   Not affected
Vulnerability Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:             Mitigation; Enhanced / Automatic IBRS; IBPB conditional; PBRSB-eIBRS SW sequence; BHI BHI_DIS_S
Vulnerability Srbds:                  Not affected
Vulnerability Tsx async abort:        Not affected

I don't see any mention of ida.

seth · 2025-08-14 19:13:08

Me neither, nor does ctrl+f
Re-install the microcode updates.

https://grml.org/
Check lscpu from there, but I'm not expecting any changes.

No idea what's up w/ the CPU, but the lacking IDA explains the behavior and is seems that should™ be there, so the identified patch is probably not wrong.
Do you have any settings in your UEFI that sound related?

haigioli · 2025-08-14 19:31:05

I don't have anything in my locked laptop UEFI that's related. There's just one switch for all overclocking: enable/disable and not nitty-gritty control. Fairly typical of laptop BIOSes.

grml lscpu to follow.

haigioli · 2025-08-14 20:18:23

grml lscpu produced no sign of ida anywhere.

What next?

seth · 2025-08-14 20:29:12

Are any BIOS updates available for your system?
googling for "i9-14900HX no ida support" I only found even more lscpu outputs w/ ida - this seems to be very specific to some sysmtes (incl. yours)

haigioli · 2025-08-14 20:49:10

Truth be told, the laptop builders have sent details of our interactions to their BIOS team and I've yet to hear something from them for three months. My first instinct on this was that it's the result of a buggy BIOS. These Clevo-based builds can be tricky with their BIOSes. I owned a handful, but this is the first time something like THIS has happened.

If I had to send them more info, what would you suggest I send? I think there's a lot of useful information here, but I don't know how much the BIOS team love their jobs.

seth · 2025-08-14 20:58:30

The lscpu output and pointing out the missing IDA

haigioli · 2025-09-10 12:37:33

@seth, this was very clearly an issue with the BIOS, which the manufacturer failed to do anything about in the four months that the problem persisted. I've replaced that laptop with a more dependable AMD-based laptop. All problems on the new one are manageable ones, fortunately. Raptor Lake CPUs are not a fun experience, in general.

Thanks for all your help.

seth · 2025-09-10 13:29:16

\o/
Well, kinda. Also

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

Arch Linux

#1 2025-08-14 03:07:37

[SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#2 2025-08-14 05:04:03

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#3 2025-08-14 06:44:14

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#4 2025-08-14 10:53:41

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#5 2025-08-14 11:12:43

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#6 2025-08-14 13:11:03

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#7 2025-08-14 13:29:10

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#8 2025-08-14 13:34:37

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#9 2025-08-14 13:40:36

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#10 2025-08-14 13:49:59

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#11 2025-08-14 13:52:06

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#12 2025-08-14 14:04:33

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#13 2025-08-14 14:19:12

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#14 2025-08-14 14:32:43

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#15 2025-08-14 18:20:20

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#16 2025-08-14 18:43:46

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#17 2025-08-14 19:00:14

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#18 2025-08-14 19:13:08

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#19 2025-08-14 19:31:05

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#20 2025-08-14 20:18:23

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#21 2025-08-14 20:29:12

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#22 2025-08-14 20:49:10

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#23 2025-08-14 20:58:30

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#24 2025-09-10 12:37:33

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

#25 2025-09-10 13:29:16

Re: [SOLVED] Kernels after 6.12.21 disable intel turbo on certain CPUs

Board footer