So, on my T14 Gen2, something went wonky in the last few days and I noticed that when I booted it up it was running acpi-cpufreq not amd-pstate. Checking the /etc/default/grub file, indeed my kernel boot parameters have been removed. Replaced those (had to do it manually, some config file is also now screwed up that I can’t do a grub-mkconfig), rebooted, and amd-pstate is working again. Yay. However, it’s using powersave as the default governor now, so no core goes above 400 MHz. Great for battery life, not so great for actually being able to accomplish anything. Schedutil still works, and I can change it manually (echo “schedutil” | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor), but how do I set schedutil as the default so I don’t need to do this every boot?
So you are using grub? In the default grub command line in /etc/default/grub add the following kernel parameter. Is this what you did?
amd_pstate=passive
Then update grub
sudo grub-mkconfig -o /boot/grub/grub.cfg
Reboot and see if is working.
Edit:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
Edit2: cpupower (Needs Installed)
cpupower frequency-info
I already fixed the not using amd-pstate, as mentioned. Although not an issue that I’m overly concerned with fixing right now, the grub-mkconfig doesn’t work anymore, either:
[root@righttorule ~]# grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
Found background: /usr/share/endeavouros/splash.png
Found linux image: /boot/vmlinuz-linux
Found initrd image: /boot/amd-ucode.img /boot/initramfs-linux.img
Found fallback initrd image(s) in /boot: amd-ucode.img initramfs-linux-fallback.img
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
error: out of memory.
error: syntax error.
error: Incorrect command.
error: syntax error.
Syntax error at line 228
Syntax errors are detected in generated GRUB config file.
Ensure that there are no errors in /etc/default/grub
and /etc/grub.d/* files or please file a bug report with
/boot/grub/grub.cfg.new file attached.
What I’m trying to fix is that since re-enabling amd-pstate, it’s now defaulting to “powersave” governor instead of “schedutil”. Is there any way to force the system to use scedutil as the default governor?
For grub output it is showing a syntax error. Maybe check your default grub command line closely.
Edit: If it isn’t updating grub then the kernel parameter won’t run.
AGain, ALREADY FIXED THE GRUB COMMANDLINE ERROR. IGNORE the grub commandline. I just manually put the amd-pstate=passive back in the actual grub file itself. That’s NOT what I’m trying to fix.
What I’m trying to fix is that since re-enabling amd-pstate, it’s now defaulting to “powersave” governor instead of “schedutil”. Is there any way to force the system to use scedutil as the default governor?
I’m just going by this? So are you saying it does update correctly now?
error: out of memory.
error: syntax error.
error: Incorrect command.
error: syntax error.
Syntax error at line 228
Syntax errors are detected in generated GRUB config file.
Ensure that there are no errors in /etc/default/grub
and /etc/grub.d/* files or please file a bug report with
/boot/grub/grub.cfg.new file attached.
jedi wave This is not the error anyone cares about fixing right now. Ignore it.
What I’m trying to fix is that since re-enabling amd-pstate, it’s now defaulting to “powersave” governor instead of “schedutil”. Is there any way to force the system to use scedutil as the default governor?
I guess I’m not really understanding how you could fix it? If you add a kernel parameter and you save it in the default grub command line and grub fails to update then the parameter is meaningless and won’t do anything. So I’m confused why you say it doesn’t matter? 
Or am i missing something here?
Edit: Maybe it does save the parameter and use it even though it’s giving the error? 
It’s easy
vi /boot/grub/grub.cfg
voila, it’s using amd-pstate exactly like it should. yes, it’s a FUTURE issue to get fixed, but the more pressing issue is that with powersave governor the system is unusable. So I need to fix THAT before I try to fix one of the grub config files having an error. Who cares if grub configuration update script works if the system is unusable?
Sorry I’m not familiar with what you are trying to do exactly with powersave governor.
Edit: Is this to do with cpupower or something else?
[ricklinux@eos-plasma ~]$ systemctl status cpupower.service
● cpupower.service - Apply cpupower configuration
Loaded: loaded (/usr/lib/systemd/system/cpupower.service; enabled; preset: disabled)
Active: active (exited) since Sun 2023-02-19 22:15:40 EST; 1min 50s ago
Process: 716 ExecStart=/usr/lib/systemd/scripts/cpupower (code=exited, status=0/SUCCESS)
Main PID: 716 (code=exited, status=0/SUCCESS)
CPU: 2ms
Feb 19 22:15:40 eos-plasma systemd[1]: Starting Apply cpupower configuration...
Feb 19 22:15:40 eos-plasma systemd[1]: Finished Apply cpupower configuration.
[ricklinux@eos-plasma ~]$
Try editing /etc/default/cpupower:
# Define CPUs governor
# valid governors: ondemand, performance, powersave, conservative, userspace.
governor='schedutil'
Hello @pebcak
I wasn’t familiar with this and reading the Arch wiki i find hard to deciper. But anyway I’m using a desktop and i did try setting this. Wasn’t sure if I was doing this right?
echo "ondemand" | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
It did set the shedutil to ondemand. Do you have to set it also in /etc/default/cpupower?
[ricklinux@eos-plasma ~]$ sudo cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
[sudo] password for ricklinux:
ondemand
ondemand
ondemand
ondemand
ondemand
ondemand
ondemand
ondemand
ondemand
ondemand
ondemand
ondemand
ondemand
ondemand
ondemand
ondemand
[ricklinux@eos-plasma ~]$
Edit: Seems to me it’s either use this or set here
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
Will this survive a reboot?
I do set the governor in /etc/default/grub:
The configuration file for cpupower is located in /etc/default/cpupower. This configuration file is read by a bash script in /usr/lib/systemd/scripts/cpupower which is activated by systemd with cpupower.service. You may want to enable cpupower.service to start at boot.
I’m just not familiar with this so i was curious. I only enabled pstates before? Then i have cpupower? Aren’t they competing with each other or doing same thing?
Do you mean for pstates?
Not sure if they are competing
From ArchWiki:
amd_pstate This driver implements a scaling driver with an internal governor for AMD Ryzen (some Zen 2 and newer) processors.
cpupower is a set of userspace utilities designed to assist with CPU frequency scaling. The package is not required to use scaling, but is highly recommended because it provides useful command-line utilities and a systemd service to change the governor at boot.
This is what I’m confused about. I have pstates set in /etc/default/grub I have cpupower installed and service running but do i have to set anything in the configs or it’s automatic? and only changes if i change the ondemand to something else? Do i have to uncomment it in that config? Any other changes or leave it commented? The Arch wiki really doesn’t explain well as far as I’m concerned.
# Define CPUs governor
# valid governors: ondemand, performance, powersave, conservative, userspace.
governor='ondemand'
# Limit frequency range
# Valid suffixes: Hz, kHz (default), MHz, GHz, THz
#min_freq="2.25GHz"
#max_freq="3GHz"
# Specific frequency to be set.
# Requires userspace governor to be available.
# Do not set governor field if you use this one.
#freq=
# Utilizes cores in one processor package/socket first before processes are
# scheduled to other processor packages/sockets.
# See man (1) CPUPOWER-SET for additional details.
#mc_scheduler=
# Utilizes thread siblings of one processor core first before processes are
# scheduled to other cores. See man (1) CPUPOWER-SET for additional details.
#smp_scheduler=
# Sets a register on supported Intel processore which allows software to convey
# its policy for the relative importance of performance versus energy savings to
# the processor. See man (1) CPUPOWER-SET for additional details.
#perf_bias=
# vim:set ts=2 sw=2 ft=sh et:
YES!! Thank you!! That’s what I was looking for but couldn’t find in the wiki.
I mean, on this, I agree 100%. I read through that wiki at least 20 times and was no closer to understanding how to force it to use one governor over another than I was before.
As far as amd-pstate vs. the governor.
The amd-psate is the driver. It will tell the governor what frequencies are available.
The governor actually sets the frequencies it should use depending on system load.
HIGHLY oversimplified, but makes the relationship between the 2 easier to understand.
I was going through the motions trying to understand and reading also but it’s confusing to me.
Edit: It looks like it’s working as i changed it back to schedutil and now it shows ondemand
You could change the scaling governor to whatever you want to be used at boot.
The cpupower.service would take care of that.
Check what cpu scaling governors are available with: cpupower frequency-info
https://wiki.archlinux.org/title/CPU_frequency_scaling#Scaling_governors