You are not logged in.
On my i9-14900HX, I have turbo mode turned on using tuned (with ppd). I had modified profiles for balanced and performance with turbo mode explicitly turned on with the pstate kernel parameter set to passive. All worked well, until the most recent update I made to kernel 6.14.6.
Now, turbo mode is turned off and reporting itself so with:
cat /sys/devices/system/cpu/intel_pstate/no_turbo
1When I run try to change the turbo state manually, I get the following:
sudo echo 0 > /sys/devices/system/cpu/intel_pstate/no_turbo
-bash: echo: write error: Operation not permittedMeaning, I no longer have permissions to change this parameter. The permissions on all files under pstate are set to:
-rw-r--r-- 1 root root 4096 May 12 23:04 no_turboWhat am I missing? What permissions have changed?
My current tuned version is tuned 2.25.1-1.
Before this problem, lscpu was reporting max frequencies at 5800MHz.
Now, it's reporting 2200Mhz with turbo boost turned on, as mentioned above.
Any help would be appreciated.
Edit:
dmesg | grep intel_pstate reports:
sudo dmesg | grep pstate
[ 0.109600] Kernel command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=884000cb-c8c2-4bcb-96ea-db9c1efe17d2 rw nvidia_drm.modeset=0 intel_pstate=passive loglevel=3 quiet
[ 1.183005] intel_pstate: Intel P-state driver initializing
[ 1.192615] intel_pstate: HWP enabled
[ 8.500545] intel_pstate: Turbo disabled by BIOS or unavailable on processor
[ 8.500554] intel_pstate: Turbo disabled by BIOS or unavailable on processorI don't quite know why HWP is enabled in passive mode. All docs for Intel kernel parameters and sysfs settings say that intel_pstate=passive implies that intel_pstate=no_hwp. Most unusual.
And, no, the BIOS is not set to turbo off. Remember: turbo was working a day ago. I'm guessing the kernel update had something to do with this, but can't be sure.
Last edited by haigioli (2025-05-13 05:09:44)
Offline
sudo echo 0 > /sys/devices/system/cpu/intel_pstate/no_turbo -bash: echo: write error: Operation not permitted
sudo only applies to the part before the pipe ( | ), therefore you have no permissions to write as normal user. Either use sudo -i for a root shell or bring sudo behind the pipe sign:
echo 0 | sudo tee /sys/devices/system/cpu/intel_pstate/no_turboEdit: also check what powertop reports in it's frequency chart.
Last edited by stfischr (2025-05-13 08:34:05)
Offline
Thanks for the feedback.
I've tried it with sudo -i, as well. Still the same result and permission problem. 'Operation not permitted'
What am I looking for with powertop's output?
Is there anything else I need to report from a command that may be helpful here?
Last edited by haigioli (2025-05-13 11:06:12)
Offline
I'm wondering, how would I investigate if the problem could be stemming from my power supply brick? I'm not familiar with the commands to do that.
Or it could be the battery, for that matter (even when plugged in). I don't know how to investigate this.
Last edited by haigioli (2025-05-13 11:21:11)
Offline
Thanks for the feedback.
I've tried it with sudo -i, as well. Still the same result and permission problem. 'Operation not permitted'
What am I looking for with powertop's output?
The frequency statistics: https://cdn.ttgtmedia.com/rms/onlineIma … ertop3.png just to make sure your favorite tool doesn't lie to you.
I've read something about boost problems with kernel 6.14, which kernel do you use (uname -a)?
Also try setting boost with cpupower and show the output of frequency-info before and after:
sudo cpupower frequency-info
sudo cpupower set --turbo-boost 0 && sudo cpupower set --turbo-boost 1
cpupower frequency-infoOffline
Ran powertop and looked at frequencies. It's not lying. There's also nothing for turbo boost listed anywhere.
The kernel I'm running is 6.14.6-arch1-1 - seemed fine with 6.14.5. This just started yesterday after a system update. This permission problem never existed before. I could go into root mode and change it before. Now, I can't. I get 'operation not permitted'.
cpupower outputs as mentioned by you @stfischr:
sudo cpupower frequency-info
analyzing CPU 16:
driver: intel_cpufreq
CPUs which run at the same hardware frequency: 16
CPUs which need to have their frequency coordinated by software: 16
energy performance preference: balance_performance
hardware limits: 800 MHz - 1.60 GHz
available cpufreq governors: conservative ondemand userspace powersave performance schedutil
current policy: frequency should be within 800 MHz and 1.60 GHz.
The governor "schedutil" may decide which speed to use
within this range.
current CPU frequency: 1.60 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yessudo cpupower set --turbo-boost 0 && sudo cpupower set --turbo-boost 1
Error setting turbo-boostcpupower frequency-info
analyzing CPU 23:
driver: intel_cpufreq
CPUs which run at the same hardware frequency: 23
CPUs which need to have their frequency coordinated by software: 23
energy performance preference: balance_performance
hardware limits: 800 MHz - 1.60 GHz
available cpufreq governors: conservative ondemand userspace powersave performance schedutil
current policy: frequency should be within 800 MHz and 1.60 GHz.
The governor "schedutil" may decide which speed to use
within this range.
current CPU frequency: 1.31 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yesNotice boost state is supported AND active?
This is weird.
Last edited by haigioli (2025-05-13 12:25:30)
Offline
I downgraded the kernel and even installed 6.12 lts. It appears not to be the direct source of the problem.
Looking at the pacman.log, I see that the problem started yesterday after updating intel-ucode (20250211-1 -> 20250512-1) and grub. After upgrading grub (2:2.12.r283.ga4da71da-1 -> 2:2.12.r292.g73d1c959-1), I ran the grub-install and grub-mkconfig programs, as per usual (it's recommended in the upgrade messages). I got no errors from grub - all clean.
Does this offer any further hints to this suddenly most unusual behaviour?
Offline
I downgraded intel_ucode to the previous versions (20250211-1). The problem persists. I haven't downgraded grub to test if that might be the problem, but I don't feel too good about doing that.
Any other clues?
Offline
I've checked the BIOS. Nothing has changed in terms of boost. As mentioned, I downgraded a few things to see if that would make a difference; it didn't (thus far).
Could this be an issue with the battery or power supply? I figured battery only because when unplugged, I still can't get the boost frequencies going.
How do I check if it's hardware?
Why would the system completely shut me out of making changes to no_turbo suddenly after all these months of working?
Any further insights are welcome.
Offline
I've been trying to figure this out most of the day to no avail.
There's just no smoking gun. Why this machine with this processor and not my other laptop intel processors of the same generation?
I've since noticed a couple of past posts outlining sort of the same problem, but no clear solution that makes sense:
https://bbs.archlinux.org/viewtopic.php?id=245976
and
https://bbs.archlinux.org/viewtopic.php?id=243656
Strange, strange, strange.
Offline
From what I can see boost is enabled but not used due to another problem. Might very well be low power or an overheat problem (see if the boost works after a cold start). It's not only boost but the whole frequency range is limited to 1,6 Ghz.
Try booting a live ISO (maybe even an Ubuntu LTS) and see if the problem persists.
Edit, now I've noticed, you are not using the intel_pstate driver and you had the same problem a year ago: https://bbs.archlinux.org/viewtopic.php?id=298554 maybe something collides with the fix you did there?
Offline
Thanks for noticing the driver reported by cpupower @stfischr. However, that is a very normal thing when running intel_pstate=passive as a kernel parameter. This is how I've been successfully running this machine since the post you linked to. I assure you that I tried setting it to active and still got the same 'operation not permitted' message. I run pstate in passive mode because I can get (when it works) reliable top clock speeds when running software that needs 'realtime' performance. Active just won't cut it for such demands.
Again, this problem appeared out of the blue in the course of an afternoon with no real reason behind it that I can discern from a software change perspective. This is why I started suspecting battery issues, or something related to hardware, or power in general. At this point, I can't physically see that this might be the case.
It's not an SELinux or apparmor case, either. I use neither of those on this machine, but all checks for good measure show those not to be in play, as expected.
This problem suddenly appeared - and I can't confirm at this point that this is the culprit - when I recharged my battery.
I can say that with all the research I've done, intel_pstate with batteries is fickle on certain machines regardless of brand. This is endlessly frustrating when you're trying to get stable performance at work, where it matters. So, needless to say, I'm not impressed.
Nonetheless, I have to soldier on and find a solution.
@stfischr, I think you're beginning to think what I'm thinking: that this might be a power problem. But, how do I check it?
Offline
@stfischr, I think you're beginning to think what I'm thinking: that this might be a power problem. But, how do I check it?
Yes, since you tried an older Kernel that definitely worked correctly in the past, this could be the reason.
Try different power sources (USB-C, other compatible power supplies) and if possible disconnect the battery. Do a cold start (not restart, turn off and then on) with each iteration of power sources. If it is a temperature issue it should work shortly after a cold boot.
Did you try a live USB distro?
Edit: just a guess, your CPU is 14th gen and I remember those were affected by the degradation issue. Not sure how you could test if your affected.
Last edited by stfischr (2025-05-14 11:35:21)
Offline
Indeed it is a 14th gen. And I'm aware of the degen issue. I'm fairly certain that I've exhausted most OS/kernel/BIOS issues that this problem could have stemmed from.
Given the suddenness of the problem appearing, and a few hints on power supply and the history of this processor out in the wild, things are pointing more and more towards the hardware side. I've contacted my vendor and awaiting instructions from them.
Meanwhile, I'm still open to hear any input and insights into something I'm missing.
Offline
This still remains a problem.
Running off of any Linux live USB key doesn't throttle the frequencies in the above ways. After installation, the problem is there. So, hardware isn't the issue. Nothing has changed on the BIOS.
throttled (service that remedies this sort of problem on some laptops) doesn't work - the service won't even start successfully, probably due to lack of permissions.
Core temps seem fine at a steady 36 to 48 deg C on humdrum tasks. I just don't get it.
Intel hasn't been helpful [yet].
Why was no_turbo able to be turned off before four days ago? Downgrading the kernel AND the ucode didn't solve the problem. So, what gives?
Doing all the research I have, I see that this sort of problem has existed for quite some time with certain Intel laptops - I had no idea. That's how throttled https://github.com/erpalma/throttled service came about in the first place.
There has to be a reason and, therefore, solution to this.
Any takers?
Last edited by haigioli (2025-05-17 11:00:00)
Offline
Hey,
if a live system doesn't have the problem, it points to any update after image release. But which component, kernel, ucode we can already exclude. I honestly have no clue where to go from here.
From your throttle link:
Writing to MSR and PCI BAR
Some time ago a feature called Kernel Lockdown was added to Linux. Kernel Lockdown automatically enables some security measures when Secure Boot is enabled, among them restricted access to MSR and PCI BAR via /dev/mem, which this tool requires. There are two ways to get around this: You can either disable Secure Boot in your firmware settings, or disable the Kernel Lockdown LSM.
The LSM can be disabled this way: Check the contents of the file /sys/kernel/security/lsm (example contents: capability,lockdown,yama). Take the contents of the file, remove lockdown and add the rest as a kernel parameter, like this: lsm=capability,yama. Reboot and Kernel Lockdown will be disabled!
Do you have secureboot enabled? A live system might not do the mentioned lockdown and therefore work flawlessly.
Offline
While I'm sure something that got updated is what made this appear out of nowhere, a faulty BIOS is also to blame.
I've been reverse engineering the motherboard and patching the DSDT to the point where I've discovered that this BIOS (it's a Clevo-based machine) is a dog's lunch. Plus, not much is exposed in the BIOS. Advanced settings are a joke. For example, overclocking is all you get. You don't get memory tuning or separate cstate controls, or Intel Turbo controls. There's an issue with what appears to be a non-existent temp sensor (a ghost sensor) that's probably the main reason why turbo mode isn't just turned on from the beginning. Whatever OS update (not kernel or ucode) that happened was probably only responsible for emphasizing a problem that was already there from the beginning (which it was).
There hasn't been a patched BIOS since I bought this machine and that's just pathetic, to be honest. You can't access SSDT because it's perplexingly embedded in DSDT - the whole thing is a confusing mess, really. However, the fact that important options and settings aren't exposed in the BIOS to begin with is just irresponsible. No user should have to be this much of a computer scientist to get to the bottom of problems like this.
That said, I'm in the middle of patching the DSDT.aml that will get rid of the ghost sensor in ACPI without suppressing ACPI and all that does work on it. Only then will I know if no_turbo can be set again. I'd have done it by now, except I have to apply the patch through UEFI, which will bypass reliance on GRUB altogether, thus ensuring that it won't be overwritten by initramfs or anything else GRUB might have in store. So, it's a bit more complicated. Once I've done it, I'll report back with results.
I will also report all this to bugzilla.kernel.org, where I've opened a case on this, already.
In the mean time, if anyone has any ideas or knowledge they want to impart, please let me know.
Last edited by haigioli (2025-05-20 03:03:47)
Offline
Can confirm this is also happening to me. I have a gigabyte G6X with a i7-13650HX running 6.14.6-arch1-1. Tried every fix in the book and chat-gpt had to offer. BIOS is very basic and secure boot is turned off. Im genuinely stumped.
sudo cpupower set --turbo-boost 0 && sudo cpupower set --turbo-boost 1
Error setting turbo-boostecho 0 | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo
0
tee: /sys/devices/system/cpu/intel_pstate/no_turbo: Operation not permittedcpupower frequency-info
analyzing CPU 13:
driver: intel_pstate
CPUs which run at the same hardware frequency: 13
CPUs which need to have their frequency coordinated by software: 13
energy performance preference: performance
hardware limits: 800 MHz - 1.90 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 800 MHz and 1.90 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency: 1.90 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yessudo dmesg | grep -i 'intel\|microcode'
[19931.450243] intel_pstate: Turbo disabled by BIOS or unavailable on processor
[19992.422443] intel_pstate: Turbo disabled by BIOS or unavailable on processor
[20462.016648] intel_pstate: Turbo disabled by BIOS or unavailable on processorOffline
Did you also try to downgrade to a previous kernel, headers, firmware, and ucode? You have to do all of those to really be sure.
I did those and still had the problem. Might work for you, though.
In my case, as well, the BIOS is FAR too basic. I've never seen a BIOS that basic before. Turned me off completely. Because of this issue and what I've discovered since dissecting the ACPI tables, I've sent in an extensive report to my laptop's manufacturers. They have to fix the BIOS. It's really atrocious.
If you try downgrading the packages above and have run mkinitcpio -P, please let me know what comes of it.
Offline
Haven't tried that , I'v been using arch for around 2 months now . Thanks for the suggestion . I will update you and see if that fixes the issue
Offline
I may have stumbled over a possible solution, although from 2022 on Ubuntu: https://www.reddit.com/r/Ubuntu/comment … urboboost/
The solution was a kernel boot parameter:
intel_idle.max_cstate=4other values might have a lower/higher impact on battery life but may work better. 0 disables intel_idle completely.
And another (related?) one: https://access.redhat.com/solutions/2895271
Offline
Fantastic find, @stfischr, but unfortunately, neither solution worked for me. Very likely because:
dmesg | grep -i turbo
intel_pstate: Turbo disabled by BIOS or unavailable on processorThere's a disconnect between my BIOS and the kernel. Early injection, late injection... nothing works because somehow, it seems, a persistent bit got switched (who knows how) telling the kernel early on that turbo doesn't exist. And because my BIOS is so dumbed down and simple, there's no way to diagnose it on that level and fix it. So, I'll have to continue to patch the DSDT in order to get it to work. I've contacted the manufacturer and informed them of the issue in great detail for their devs. Ultimately, they'll have to expose everything necessary in the BIOS, like any decent BIOS should. Dumbed down BIOSes only cause trouble, like this one. Plus, you can tell from the ghost sensors it picks up that this was a copy-paste hack. Not cool at all.
Hopefully, they'll fix it soon. Meanwhile, I have some real decisions to make.
Once again: thanks for your incredible digging. This will hopefully provide an answer for someone else.
Last edited by haigioli (2025-05-21 12:21:42)
Offline
Can confirm that did not solve the issue for me aswell. Did you try booting into windows firstly without then with a tool like QuickCPU and check the frequencies from there?
Offline
Thanks for seconding the results.
I don't have access to Windows at all. Cannot confirm frequencies in that manner, unfortunately.
I can say that Arch live media, as of 2025.05.01, which features kernel 6.14.4, does not exhibit this problem. This suggests something in an update somewhere is making the early on in the boot process of the installed media deny that the CPU even has turbo capability. Truly strange. Can't pinpoint what's doing it. Either way, it doesn't help that the BIOS is inherently buggy and far too simplistic with too many options hidden away.
I have a couple of other things in mind to test. Will circle back when I have results.
Offline
Just updated to the new kernel and still the issue persists. Are you able to confirm if this issue exits on LTS kernel?
Offline