OP
Debian_SuperUser
Member
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.
How to limit CPU frequency at early boot?
- Thread starter Debian_SuperUser
- Start date
@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.
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.
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.
OP
Debian_SuperUser
Member
Throttlestop on Windows can unlock TB even when disabled in firmware.
Then just tell me already!! I have been wanting to do this for so long, even if that might not solve the problem.
OP
Debian_SuperUser
Member
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.
OP
Debian_SuperUser
Member
OP
Debian_SuperUser
Member
Yes, I was about to mention that, but I was just waiting for @GFdeb12 for a reply. 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?
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=""
OP
Debian_SuperUser
Member
But I already said this -
If you can't solve that, then try answering this -
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.
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.
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.
How to use AMD P-State in Linux
Up to date guide is here Linux 5.17 is here and just around the corner for Arch users who dont build their own Kernels and have it already. Even if you do here is the short and easy of using the new P-State Driver for AMD CPUs. Ondemand seems to deliver the best performance/power savings...
forum.endeavouros.com
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.
OP
Debian_SuperUser
Member
@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). -
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/ -
The error I get from systemctl status and journalctl -
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.
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/bashsudo cpupower frequency-set -u 3.1GHz && sudo cpupower frequency-set -d 3.1GHzOne 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.targetWants=local-fs.target sysinit.target[Service]Type=oneshotExecStart=/usr/bin/cpupower frequency-set -u 3.1GHz; /usr/bin/cpupower frequency-set -d 3.1GHzRemainAfterExit=true[Install]WantedBy=multi-user.targetThe 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 argumentJun 22 18:22:14 Ubuntu systemd[1]: 3100MHz.service: Main process exited, code=exited, status=234/n/aJun 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.
change
Code:
ExecStart=/usr/bin/cpupower frequency-set -u 3.1GHz; /usr/bin/cpupower frequency-set -d 3.1GHzto
Code:
ExecStart=/bin/sh -c "/usr/bin/cpupower frequency-set -u 3.1GHz && /usr/bin/cpupower frequency-set -d 3.1GHz"
OP
Debian_SuperUser
Member
@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?
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?
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"
OP
Debian_SuperUser
Member
@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.
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.
Latest posts
-
-
-
Solved Select and copy ALL code generated in the terminal THE EASY WAY- Latest: Sherri is a Cat
-