─────────────────────────────────────────────────────
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
Btw, I found this to be a bug in our script. When no min/max frequencies are explicitly selected, it assumes the first/left value to be the lowest and the last/right one to be the highest, and sets them explicitly. Found something similar to happen on a NanoPi Fire3, which uses an ancient vendor kernel, but it was the other way round: the minimum frequency was set to max. I guess it depends on whether the min or max assigned frequency take procedure.
On my RPi 2, and I guess most systems: The lowest frequency wins: When assigning a min frequency higher than the max, or a max frequency that is higher than the min, in both cases, the limit is capped to the lower frequency.
On the NanoPi Fire3: If one tries to assign a max frequency lower than the assigned min frequency, or a min frequency higher than the assigned max frequency, the assignment fails. Since our script assigned the the max possible frequency as min limit first, assigning the max limit failed, so that in practice it always ran on max frequency.
I am actually not sure why we assign the min/max values at all, if not defined by the admin. Probably there were reasons where those scheduler limits were not at the actually possible min/max. So for now I’ll leave it like that, something we can experiment with later, or once we dropped support for all SBCs with legacy kernel versions, like the NanoPi Fire3, planned for end of this year.
.