On 13/07/2022 17:12, killermoehre@xxxxxxx wrote:
This must explain why my modprobe.d (of acpi_cpufreq) seems to always work but not why tmpfiles.d or a .service unit :
Actually, your modprobe.d is much too late
Well, maybe we don't talk about the same thing: I'm only interested in
/sys/devices/system/cpu/cpufreq/boost file.
I can echo 0 or 1 into this file anytime long after boot and verify
(running 'stress' for instance) in /proc/cpuinfo that core frequencies
are boosted or limited (lscpu does not seem to update the info though).
Besides, rmmod'ing the acpi_cpufreq module makes the 'boost' file vanish
(which seems normal according documentation)
The driver absolutely loaded, as stated earlier. What I find interesting is the error message you get with
/sys/devices/system/cpu/cpufreq/boost: Permission denied
Agreed. Assuming module is loaded (hence file present) maybe there's a
critical section where it does not have the correct permission ? However
a standard systemd service (with default dependencies) comes quite late
in the boot process...
Did it failed because the file didn’t exists? Maybe the path you used is wrong?
I don't know. I initially thought about a race thinking that it was some
systemd services (udevd.service ?) that created or chmoded the file. But
(see above) this does not seem to be the case or is it ?
In this case I think your best bet is to disable the most option in the BIOS/UEFI. At least https://urldefense.com/v3/__https://docs.kernel.org/admin-guide/pm/cpufreq.html*rationale-for-boost-control-knob__;Iw!!JFdNOqOXpB6UZW0!t1eSenFnShc2J6NFFCaKdU-KiALOpOCGtva-oRXD7dih4zXs-yXPrA0wcas3OKKLGw4wKo646cvZDartCoacDVmvAi4$ is speaking of that.
If you don’t have such option in the BIOS/UEFI settings, you could try some udev rule reacting to the /sys entry. Something like
`/etc/udev/rules.d/20-disable-cpu-boost.rules`
```
KERNEL=="cpu", ATTR{cpufreq/boost}=="1", ATTR{cpufreq/boost}:="0"
```
Thanks yes, I thought about it. Would like to understand what's failing
in my original naive setting (tmpfiles or service).
Thanks again anyway.
--
Thomas HUMMEL
