FS#75897 - [cpupower] systemd service runs too early

Attached to Project: Community Packages
Opened by John K. (NeK) - Tuesday, 13 September 2022, 14:59 GMT
Last edited by Toolybird (Toolybird) - Friday, 30 September 2022, 21:33 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To No-one
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
I have enabled cpupower systemd service but when rebooting the cpupower frequency governor is not changed. If I manually start the service (i.e., systemd restart cpupower) it does change the governor. Doing a systemctl status the service reports no errors.

This seemsI like a race condition. That the cpupower service runs very early in the boot process and that something else is resetting the governor right after that.

Additional info:
package version: 5.19-1

Steps to reproduce:
1. install cpupower package
2. edit the /etc/default/cpupower file and replace the governor='ondemand' with governor='performance' and save it
3. enable the service (systemctl enable cpupower)
4. reboot the system
5. check the active cpu governor by executing cpupower frequency-info
This task depends upon

Closed by  Toolybird (Toolybird)
Friday, 30 September 2022, 21:33 GMT
Reason for closing:  Not a bug
Additional comments about closing:  "no bug. 'power-profiles-daemon' package was interfering and conflicting with this package. I removed it and it now works well."
Comment by Toolybird (Toolybird) - Tuesday, 13 September 2022, 21:37 GMT
This looks similar to  FS#47665 . Can you follow the advice there and load the kernel module early in your initramfs à la early kms [1]?

[1] https://wiki.archlinux.org/title/Kernel_mode_setting#Early_KMS_start
Comment by John K. (NeK) - Sunday, 18 September 2022, 00:51 GMT
I tried to pinpoint the Kernel Module that is relevant and responsible but I couldn't. According to the wiki my Intel CPU should use 'intel_pstate' but lsmod | grep -i state only brought up 'intel_cstate' (notice the c instead of p). I added both intel_cstate intel_pstate in MODULES=(XXXX) of /etc/mkinitcpio.conf, run 'mkinitcpio -P', rebooted but the active governor was still the 'powersave' one.
Comment by Toolybird (Toolybird) - Wednesday, 21 September 2022, 03:41 GMT
> I tried to pinpoint the Kernel Module that is relevant and responsible but I couldn't

Then I'd recommend you take this to the support channels (forum/IRC/etc) to seek help in figuring out the correct module(s) for early load.
Comment by John K. (NeK) - Friday, 30 September 2022, 15:15 GMT
This doesn't seem to be related with  FS#47665 . The cpupower systemd unit starts and exits successfully, long after initramfs and after the modprobe unit has started and ended. I assume that all relevant kernel drivers must already be loaded at that point and therefore something else must the cause.
Comment by John K. (NeK) - Friday, 30 September 2022, 15:48 GMT
I edit /usr/lib/systemd/scripts/cpupower and put some logs and I can verify that the cpupower unit executes cpupower successfully and it changes the governor (verified it by executing "cpupower frequency-info" at the end of the script). However, when I log in and I execute the same command, the active governor is back again at "powersave".

Something is actually changing the governor back to "powersave" and I'll have to investigate it. any ideas? gnome perhaps (please tell gnome doesn't mess with these things)?
Comment by John K. (NeK) - Friday, 30 September 2022, 16:00 GMT
Of course. There is another service in my system named 'power-profiles-daemon' which is being used by gnome-shell (and failing miserably doing so) which conflicts with cpupower systemd unit.

I removed the 'power-profiles-daemon' package with pacman and now everything works as expected.

Please close this. Thanks.

Loading...