• We had to restore from a backup today after a failed software update. Backup was from 0000 EDT and restored it at 0800 EDT so we lost about 8hrs. Today is 07/20/2024. More info here.

How to limit CPU frequency at early boot?

You can't use the msr-tools (wrmsr) until sysinit.target has been loaded.

Unfortunately, there is no program/tool to accomplish this. You have to do it with scripts.
Well then I can have TB disabled in firmware, and use msr-tools at desktop to unlock TB. But I just don't know which register to write to and what value.
 


@Debian_SuperUser
Inspired by your comments in #13, despite the derision, and inspired by @GFdeb12, it sent me to various websites ending here: https://cdrdv2.intel.com/v1/dl/getContent/671098

It's hard to see how altering the msr registers would help if they depend on the loading of the msr module by the kernel, but maybe I'm mistaken. By the time that's loaded, the kernel has already loaded its core functioning. On the other hand, if there's some low level boot code, maybe assembly code, included in the kernel, maybe something is possible with this, but I can't say any more about that. The only other thing that came to mind was undervolting.
 
Well then I can have TB disabled in firmware, and use msr-tools at desktop to unlock TB. But I just don't know which register to write to and what value.

If you disable turboboost in the firmware, you probably won't be able to re-enable it with msr-tools.

I can give you the value to disable it with msr-tools, but it won't help you. You can't input the value before sysinit.target is loaded.

If you can tell me exactly at what point during boot your notebook is having issues, we might be able to analyze the problem more precisely and take appropriate action.
 
If you disable turboboost in the firmware, you probably won't be able to re-enable it with msr-tools.
Throttlestop on Windows can unlock TB even when disabled in firmware.

I can give you the value to disable it with msr-tools,
Then just tell me already!! I have been wanting to do this for so long, even if that might not solve the problem.
 
INTEL IA32_MISC_ENABLE Register = 0x1a0
DISABLE TURBOBOOST = 0x4000850089

Good luck.
Oh no way, it actually worked! This solves all problems. Now I can have TB permanently disabled in firmware, and enable it (which It seems to be 0x850089) in the OS at runtime with the frequency lock.
 
@GFdeb12

Bad news. I just now tried actually disabling Turbo Boost in UEFI, and changing that register does not work. It is not able to turn on turbo after turbo is disabled in firmware. Throttlestop on Windows must be changing some other register or finding a way to override firmware settings.
 
From: https://docs.kernel.org/admin-guide/pm/cpufreq.html
The boost File in sysfs

This file is located under /sys/devices/system/cpu/cpufreq/ and controls the “boost” setting for the whole system. It is not present if the underlying scaling driver does not support the frequency boost mechanism (or supports it, but provides a driver-specific interface for controlling it, like intel_pstate).

If the value in this file is 1, the frequency boost mechanism is enabled. This means that either the hardware can be put into states in which it is able to trigger boosting (in the hardware-based case), or the software is allowed to trigger boosting (in the software-based case). It does not mean that boosting is actually in use at the moment on any CPUs in the system. It only means a permission to use the frequency boost mechanism (which still may never be used for other reasons).

If the value in this file is 0, the frequency boost mechanism is disabled and cannot be used at all.

The only values that can be written to this file are 0 and 1.

Whether that's of any use, I can't say.
 
Where can I run this at the earliest stage of the boot process?
Most likely by adding it to your boot-loader boot options, /etc/default/grub. Add it to the end of the following line.
Code:
GRUB_CMDLINE_LINUX=""
Generate your Grub configuration and reboot.
 
But I already said this -
Throttlestop on Windows can unlock TB even when disabled in firmware.
Throttlestop on Windows must be changing some other register or finding a way to override firmware settings.
If you can't solve that, then try answering this -
I could do that I can disable turbo through this at the earliest stage in the boot process possible, and it might work. Where can I run this at the earliest stage of the boot process?
I have noticed that the system will pretty much never crash when loading the kernel. When it crashes, it mostly will crash after some steps of Ubuntu mounting the snap packages, and it will rarely crash when trying to init systemd.

Most likely by adding it to your boot-loader boot options, /etc/default/grub. Add it to the end of the following line.
Only kernel parameters go there right? Changing the turbo option in the runtime system files or using the wrmsr command is not a kernel parameter. I want to know what is the highest stage in the boot process I can turn of turbo using the system files or using the wrmsr command. Both of this will need to have TB enabled in the firmware, but it would be better if I could know a way to override the firmware setting and enable TB, as Throttlestop can do in Windows.
 
Only kernel parameters go there right?
Since @osprey linked to docs.kernel.org I would be assuming there are kernel parameters listed there too or you can try adding it to a file in /etc/modprobe.d/
I would think setting p-state is similar to setting cpu frequency, though I cannot speak from experience.
 
I could do that I can disable turbo through this at the earliest stage in the boot process possible, and it might work. Where can I run this at the earliest stage of the boot process?

Create a systemd rule and start it after local-fs.target and before apparmor.service. Grant "msr" write permissions. Check if "msr" indeed has write permissions. Consider temporarily disabling secure-boot if necessary.
 
@GFdeb12

So I was trying to create a systemd service to disable turbo and then another one to enable, but then I thought why just not create a service that locks the clock speed to 3.1 GHz, as I do it now with cpupower?

AI recommends that I should start it after sysinit.target, as the msr kernel module needs to be loaded. But I am having a problem launching it, and it probably is some dumb syntax error or something.

My current bash script that I run to set the frequency to 3.1 GHz (if you are wondering, I keep the power saver governor active so that the system doesn't crash when it gets after loading the governor. Of course the problem here is that everything is delicate before the governer is loaded). -
#!/bin/bash

sudo cpupower frequency-set -u 3.1GHz && sudo cpupower frequency-set -d 3.1GHz

One thing to note that the user space governor is not loadable on my system, so I just do it like this above.

My systemd service in /etc/systemd/system/ -

[Unit]
Description=Sets CPU frequency to 3.1GHz.
After=local-fs.target sysinit.target
Wants=local-fs.target sysinit.target

[Service]
Type=oneshot
ExecStart=/usr/bin/cpupower frequency-set -u 3.1GHz; /usr/bin/cpupower frequency-set -d 3.1GHz
RemainAfterExit=true

[Install]
WantedBy=multi-user.target

The error I get from systemctl status and journalctl -

Jun 22 18:22:14 Ubuntu systemd[1]: Starting 3100MHz.service - Sets CPU frequency to 3.1GHz....
Jun 22 18:22:14 Ubuntu cpupower[1060]: invalid or unknown argument
Jun 22 18:22:14 Ubuntu systemd[1]: 3100MHz.service: Main process exited, code=exited, status=234/n/a
Jun 22 18:22:14 Ubuntu systemd[1]: 3100MHz.service: Failed with result 'exit-code'.
Jun 22 18:22:14 Ubuntu systemd[1]: Failed to start 3100MHz.service - Sets CPU frequency to 3.1GHz..

What is wrong? Invalid argument means it is a dumb syntax mistake probably.

Also, just when I was writing this post, another thought came to my mind. Instead of creating a systemd service, what if I modify the current power governor directly? I tried to find how to but couldn't. AI also suggested using crontab as an alternative to a systemd service, but I doubt that I would be able to run at as early as possible.
 
ExecStart=/usr/bin/cpupower frequency-set -u 3.1GHz; /usr/bin/cpupower frequency-set -d 3.1GHz

Jun 22 18:22:14 Ubuntu systemd[1]: Starting 3100MHz.service - Sets CPU frequency to 3.1GHz....
Jun 22 18:22:14 Ubuntu cpupower[1060]: invalid or unknown argument
Jun 22 18:22:14 Ubuntu systemd[1]: 3100MHz.service: Main process exited, code=exited, status=234/n/a
Jun 22 18:22:14 Ubuntu systemd[1]: 3100MHz.service: Failed with result 'exit-code'.
Jun 22 18:22:14 Ubuntu systemd[1]: Failed to start 3100MHz.service - Sets CPU frequency to 3.1GHz..

What is wrong? Invalid argument means it is a dumb syntax mistake probably.

change
Code:
ExecStart=/usr/bin/cpupower frequency-set -u 3.1GHz; /usr/bin/cpupower frequency-set -d 3.1GHz

to
Code:
ExecStart=/bin/sh -c "/usr/bin/cpupower frequency-set -u 3.1GHz && /usr/bin/cpupower frequency-set -d 3.1GHz"
 
@GFdeb12

Well that worked, but it has a problem. It doesn't start as soon as possible. As I said, my system when crashes, will mostly crash after a few steps after the snap packages have been loaded. I can see that my service gets executed much later.

Interestingly, the service gets executed at one point, but I can see the output of cpupower after some steps of the service initialization, and just after the loadcpufreq.service has been run. But, it could be just because systemd runs stuff in parallel and very fast, so other stuff got completed while cpupower was running, and not that cpupower got executed late.

Still, is there any priority or anything that I have to change to make it launch earlier?
 
But, it could be just because systemd runs stuff in parallel and very fast, so other stuff got completed while cpupower was running, and not that cpupower got executed late.
You could try booting with only one core. Perhaps that will help. If it works, you can create a systemd rule to bring the remaining cores online.

Code:
GRUB_CMDLINE_LINUX_DEFAULT="intel_pstate=enable maxcpus=1"
 
@GFdeb12

Ah yes, should have mentioned that using less cores increases stability. Now I don't think it will crash. But still, the boot now is actually kind of slow with 1 thread that I have given. I might try with more, but that is only going to increase the chances of crashes.

But still, I want to know if there is any way to run my service that locks the clock speed a bit earlier. But even with that, it wouldn't solve the sometimes crashing when loading systemd itself, and with using less cores, which also is directly a kernel parameter so it is executed the earliest. I could use maxcpus in combination with my clock speed service. Once I know that my clock speed service has been initialized, I can run another service that unlocks all the threads. But I would still like to run my service the earliest.
 


Top