Hello everyone.
I have this hardware: fireinfo.ipfire.org - Profile 9d73b2b007ea75a8c15d748d8ac07e6effd8ec8f
And after updating to "IPFire 2.27 (aarch64) - Kernel Update 173 Development Build: master/fa2f6cb6 " everything seems to work correctly. 
Thank you very much to all!!!.
There is still a problem with high CPU and memory load by openvpn-authenticator
after red0 reconnection
and after stopping and starting OpenVPN Server in the WUI
Yes, already fed into the bug.
It looks like the core update didn’t actually update the openvpn-authenticator code. @pmueller is going to have a look at what happened.
graph for Cpu freq after update to core 173 is acting up again. already ran through the steps to reset.
anyone else having this issue?
EDIT: turned off logical processors in bios and graph is working again, ipfire forcing them off creates a problem with the collectd plugin seeing the unavailable processors as device busy
Feb 12 09:09:14 ip collectd[3355]: cpufreq: fgets: Device or resource busy
Feb 12 09:09:14 ip collectd[3355]: read-function of plugin `cpufreq' failed. Will suspend it for 60 seconds.
My test system showing increased CPU frequency too since 172 > 173.
Celeron J1900 4 cores 4 threads, so no HyperThreading capability.
https://fireinfo.ipfire.org/profile/054fd385a14f63ed882431dd51fb6ce62493e07e
Maybe here is the cause of the problem
If that is the problem then it has been like that for at least 11 years. I went back to CU50 and that plugin has been commented out the whole while, probably always.
Probably need to look at the code for the WUI page with the cpu freq graphs and see where it is getting its data from and track back from that.
collectd is using lm-sensors for the cpufreq data which uses the Plugin sensors which is enabled.
Why that might be varying from CU to CU I don’t know. It is not related to any change in lm-sensors as the last change in that was April 2021 and there was no mention of cpu freq in the Changelog from that change.
The reason why the “CPU frequency Graph” is missing is the appearance of the # sign .
But
What is the reason for the appearance of the # sign ?
Ive never touched the collectd.conf on any of my ipfire systems and it is not commented out on the ones ive checked
Been able to clarify things with some more searching in the IPFire git repository.
The default for collectd.conf is for the cpufreq plugin to be commented out but if cpufreq is found in the
/sys/devices/system/cpu/ tress then there is code in the collectd initscript to uncomment the cpufreq plugin in collectd.conf.
So it is dynamically modified depending on the capabilities of the processor available on the system.
Last change to fix the collectd cpu plugin enable code was in August 2018
As the cpufreq info comes from the kernel sysinfo the only thing I can think of for the change in frequency value is the change of the kernel from 5.15.71 introduced in CU171 to 6.1.9 that has been added into CU173 Testing.
I see kernel 6.1.11 released and has a fair few CPU related changes in there.
Not sure if any apply to Intel (most seem PowerPC), but might be worth rebasing if time allows.
kernel 6.1.11 has been merged into next and so will be released with CU174.
kernel 6.1.11 has been added to the latest testing release of CU173 (master/8284f978). It is running, without issues, in x86_64 and armv6l.
A heads up to confirm CU 173 Testing with kernel 6.1.11 still has the elevated CPU levels.
A heads up regarding elevated CPU levels after installing CU 173 production on various boxes.
Quite a few of my boxes experienced significant CPU frequency rise after 172 > 173.
I have found the workaround is to install Pakfire module cpufrequtils and then reboot.
Found after the reboot, removing cpufrequtils and rebooting again seems to keep the lower CPU levels.
I guess cpufrequtils writing out a config file on boot. Probably best to leave installed on problem boxes.
I’d advise checking your boxes for elevated CPU frequencies after CU 173 and apply fix as required.
Perhaps this has something to do with what you are seeing.
If my understanding is correct
Cpu is set to performance "default "
When you Uninstall cpufrequtuls
Is it not fully restored to original file?
