On Thu, 18 Jul 2024 12:31:59 +0300 jim_p <pitsior...@outlook.com> wrote:
[...] > Then I discovered linux-cpupower, which I used by running "cpupower > frequency-set -g powersave" on every boot. Hi! How did you use to run "cpupower frequency-set -g powersave" ? Manually? Or did you drop that line in some script executed at boot (such as the deprecated rc.local)? If I understand correctly, it was working, without failing, when you followed this strategy. > > I was also annoyed by the lack of a systemd service and a config file in > debian, until I tried the attached files here. Thanks for testing them! :-) > I am having the following issue. > The service sometimes fails to start on boot. What do you mean by "sometimes"? Do you mean that it works on some boots and fails on some other boots, in a seemingly unpredictable manner? Or did you identify some pattern in these success/error cases? > I added the -x parameter and > removed the "> /dev/null || ESTATUS=1" from line 20 of /usr/libexec/cpupower > so > as to get a better error output, but all I get is this > > $ sudo journalctl -b -u cpupower.service > Jul 14 19:50:41 pc systemd[1]: Starting cpupower.service - Apply cpupower > configuration... > Jul 14 19:50:41 pc cpupower[337]: + ESTATUS=0 > Jul 14 19:50:41 pc cpupower[337]: + test != > Jul 14 19:50:41 pc cpupower[337]: + PARS= -g powersave > Jul 14 19:50:41 pc cpupower[337]: + PARS= -g powersave > Jul 14 19:50:41 pc cpupower[337]: + test -g powersave != > Jul 14 19:50:41 pc cpupower[337]: + cpupower frequency-set -g powersave > Jul 14 19:50:41 pc cpupower[343]: Setting cpu: 0 > Jul 14 19:50:41 pc cpupower[343]: Error setting new values. Common errors: > Jul 14 19:50:41 pc cpupower[343]: - Do you have proper administration rights? > (super-user?) > Jul 14 19:50:41 pc cpupower[343]: - Is the governor you requested available > and > modprobed? > Jul 14 19:50:41 pc cpupower[343]: - Trying to set an invalid policy? > Jul 14 19:50:41 pc cpupower[343]: - Trying to set a specific frequency, but > userspace governor is not available, > Jul 14 19:50:41 pc cpupower[343]: for example because of hardware which > cannot be set to a specific frequency > Jul 14 19:50:41 pc cpupower[343]: or because the userspace governor isn't > loaded? > Jul 14 19:50:41 pc cpupower[337]: + PARS= > Jul 14 19:50:41 pc cpupower[337]: + test != > Jul 14 19:50:41 pc cpupower[337]: + exit 0 > Jul 14 19:50:41 pc systemd[1]: Finished cpupower.service - Apply cpupower > configuration. > > Any ideas? Not many, unfortunately, at least on my side. It works for me™, which, I acknowledge, doesn't mean much... Of course you installed cpupower.service into /usr/lib/systemd/system/, hence we can assume that systemd is executing the /usr/libexec/cpupower script as root. And anyway, it must be so, otherwise it would *always* fail... Maybe the systemd service sometimes gets started too early in your system, but I don't understand how it could be: as far as I can see, cpupower only needs to be able to load kernel modules... so how can it be too early?!? People from the Debian Kernel Team will sure understand these things much better than me: could someone please step in and share his/her insight? In the meanwhile, let's try to add After=systemd-modules-load.service to the [Unit] section of cpupower.service, as in the attached file. Or maybe After=remote-fs.target ? Could you please test this modification and see whether it cures your issue? -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
cpupower.service
Description: Binary data
pgpZlnhojSnaT.pgp
Description: PGP signature
