─────────────────────────────────────────────────────
DietPi CPU Info
Use dietpi-config to change CPU / performance options
─────────────────────────────────────────────────────
Architecture | x86_64
Temperature | 12 °C / 53 °F : Who put me in the freezer!
Governor | schedutil
Current Freq Min Freq Max Freq
CPU0 | 799 MHz 800 MHz 800 MHz
CPU1 | 799 MHz 800 MHz 800 MHz
CPU2 | 799 MHz 800 MHz 800 MHz
CPU3 | 799 MHz 800 MHz 800 MHz
[ INFO ] DietPi-CPU_info | CPU current frequency, may be affected by this script, due to the processing required to run it.
As you can see in scaling_available_frequencies there is 2050MHz available, but other tools don’t recognize it. In fact, the single cpu is slow. Even the dietpi-config tools (the one to adjust conservative vs performance CPU) is just showing 800MHz as option. Finally, when I check in UEFI at boot, it shows correctly 2050MHz as CPU speed.
root@DietPi:/home/dietpi# cpu
─────────────────────────────────────────────────────
DietPi CPU Info
Use dietpi-config to change CPU / performance options
─────────────────────────────────────────────────────
Architecture | x86_64
Temperature | 4 °C / 39 °F : Who put me in the freezer!
Governor | ondemand
Throttle up | 50% CPU usage
Current Freq Min Freq Max Freq
CPU0 | 800 MHz 800 MHz 800 MHz
CPU1 | 800 MHz 800 MHz 800 MHz
CPU2 | 800 MHz 800 MHz 800 MHz
CPU3 | 800 MHz 800 MHz 800 MHz
[ INFO ] DietPi-CPU_info | The current CPU frequency may be affected by processing this script itself.
Interesting. Indeed also the reversed scaling_available_frequencies, I am sure this is related to the issue, that CPUFreq e.g. then takes the last one as highest, while in your both cases it is the smallest. Probably affects all AMD Athlon Kabini CPUs, at least the 5350 and 5150 the two of you use are from this very same family.
Does it work to manually adjust the max scaling frequency?
echo 1600000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
cpu
EDIT: One more thing to check, as there are two scaling drivers available for AMD CPUs:
root@DietPi:/home/dietpi# echo 1600000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
cpu
─────────────────────────────────────────────────────
DietPi CPU Info
Use dietpi-config to change CPU / performance options
─────────────────────────────────────────────────────
Architecture | x86_64
Temperature | 33 °C / 91 °F : Cool runnings
Governor | ondemand
Throttle up | 50% CPU usage
Current Freq Min Freq Max Freq
CPU0 | 1188 MHz 1600 MHz 1600 MHz
CPU1 | 819 MHz 800 MHz 800 MHz
CPU2 | 1515 MHz 800 MHz 800 MHz
CPU3 | 869 MHz 800 MHz 800 MHz
[ INFO ] DietPi-CPU_info | The current CPU frequency may be affected by processing this script itself.
So to fix the temperature output you needed to load a particular platform driver nct6775, which obviously was not loaded OOTB?
So manually raising the max temperature at least worked. What is interesting and somewhat weird is that all CPUs seem to have their own governor policy, since CPU0 has max 1600 MHz applied correctly, but the others not, while especially CPU2 has a current frequency of 1515 MHz despite that. Now I want to see the full picture:
for i in /sys/devices/system/cpu/cpufreq/policy[0-9]
do
echo -n "$i/affected_cpus: "
cat "$i/affected_cpus"
echo -n "$i/scaling_max_freq: "
cat "$i/scaling_max_freq"
echo -n "$i/scaling_governor: "
cat "$i/scaling_governor"
done
In dietpi-software performance option you can set min and max frequencies for all CPUs in any case.
amd_pstate=passive would need to be added to kernel command-line arguments to enable it. There is an “active” mode, which is however surely not supported by such old CPU. There is a tiny risk that this driver is generally not supported by your CPU and that it makes boot failing.
Regarding the nct6775, I had to calibrate lm-sensors. Then the sensors came up and I searched and found that this could be the issue. Not even sure if this fixed it and even then why…
I’ve looked at the driver and it seems like it is supposed to be compatible with Zen2 and upwards. As far as I know my CPU is Zen1.
I’ve also been able to set the CPU freq Min and Max manually in schedutil. What I’ve found weird is, when I’ve set Max to 1600 Min would automatically go to 1600. Had to manually set it to 800.
root@DietPi:/home/dietpi# cpu
─────────────────────────────────────────────────────
DietPi CPU Info
Use dietpi-config to change CPU / performance options
─────────────────────────────────────────────────────
Architecture | x86_64
Temperature | 33 °C / 91 °F : Cool runnings
Governor | schedutil
Current Freq Min Freq Max Freq
CPU0 | 800 MHz 800 MHz 1600 MHz
CPU1 | 800 MHz 800 MHz 1600 MHz
CPU2 | 800 MHz 800 MHz 1600 MHz
CPU3 | 800 MHz 800 MHz 1600 MHz
[ INFO ] DietPi-CPU_info | The current CPU frequency may be affected by processing this script itself.
You mean when you raised /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq manually, /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq raised as well?
Indeed it has an own policy for each core, which is uncommon as well. In that case dietpi-config is handy, to apply things to all CPU cores.
As cpu output above shows current frequencies as 800 MHz only, you can check /sys/devices/system/cpu/cpufreq/policy*/stats/time_in_state by times to see whether all p-states are used.
Ah even the amd_pstate=passive? The active one mentions CPU requirements, for the passive one I was not sure. I mean as of the linked benchmarks, the AMD scheduler does not seem to have much benefits anyway, and with the passive mode even less. I was just wondering, that if it works at all, whether the CPUFreq setup and behavior would be more consistent. These inverse p-states, that hence the max frequency equals min by default, and that min changes when max is changed (as you said), that all looks like the chip is providing info in a way the default scheduler does not expect. At least it can be fixed/changed manually.
I will try later. I’ve changed to Ubuntu to see if I encounter similar errors. The temp error presets and it looks like that nct6776 isn’t reliable for cpu temp.
Regarding the scheduler. On Ubuntu it seems to get the right max and min.
But I am most likely going back to dietpi, so I will be updating on my tinkering.
By the way: /sys/devices/system/cpu/cpufreq/policy*/stats/time_in_state gave me a command not found
.