[SOLVED] APU - Is your CPU clock stuck at low frequency after some time?

[thowe]

Update:

Since BIOS version v4.14.0.1 (June 2021) the problem seems to be fixed:

with the recent v4.14.0.1 we have fixed some issues related to CPU boost and C-states which may help with the problem of idling CPUs and stuck frequencies. It should also improve the stability of the BSD systems.

coreboot didn't include the core C6 (CC6) save state memory in the memory map. OS could accidentally access this memory and overwrite core states. CC6 is required for CPU boost to work and is a lower power state for a core.

I can confirm that with the current version v4.14.0.6 I don't see the problem anymore. I.e. with the current BIOS you can turn on the powerd under OPNsense on an APU2 and leave it on highadaptive. The CPU adapts well to the load and always goes back to maximum frequency if necessary.

If you don't need gigabit internet, the APU2 is still an extremely proven and stable base for OPNsense. I have two of them.

[thowe]

Originally it effectively looked like the problem was solved for quite some time.

To be sure, I just logged into the firewall again and looked.

Unfortunately, I find that despite new firmware, the problem is still there.

The BIOS developers have been informed. In the meantime better turn off Powerd or set it to maximum.

[johnmcallister]

I don't think I'm necro'ing this thread since I'm using identical hardware (APU2E4,) just on a later version of OPNsense which may have broken something.

My system:

Code: [Select]

root@myopnsenserouter:~ # uname -a
FreeBSD myopnsenserouter.mydomain.com 13.2-RELEASE-p10 FreeBSD 13.2-RELEASE-p10 stable/24.1-n254984-f7b006edfa8 SMP amd64
I installed turbostat, and after successfully loading the kernel module:

Code: [Select]

kldload cpuctl

when running turbostat it executes and appears to start OK, but after 5 seconds it core-dumps:

Code: [Select]

root@myopnsenserouter:~ # turbostat
turbostat version 17.06.23 - Len Brown <lenb@kernel.org>
CPUID(0): AuthenticAMD 13 CPUID levels; family:model:stepping 0xf:30:1 (15:48:1)
CPUID(1): SSE3 MONITOR - - - TSC MSR - -
CPUID(6): APERF, No-TURBO, No-DTS, No-PTM, No-HWP, No-HWPnotify, No-HWPwindow, No-HWPepp, No-HWPpkg, No-EPB
CPUID(7): No-SGX
NSFOD /sys/devices/system/cpu/cpu3/cpufreq/scaling_driver
Floating exception (core dumped)


Here is the dmesg output:

Code: [Select]

pid 65735 (turbostat), jid 0, uid 0: exited on signal 8 (core dumped)
My intuition is that the device tree or device names have moved & turbostat is simply crashing because it can't find the device to sample?

Any further hints or comments as to how to fix this, or if turbostat's functionality is broken by changes in OPNsense over the past couple years?

[johnmcallister]

Replying further, as I found another relevant thread on this turbostat core-dump issue:

https://forum.opnsense.org/index.php?topic=30148.msg145554#msg145554

In my case, I think I did install the most-recent version of turbostat, but it's still crashing. Oh well, I guess no resolution at this time:

Code: [Select]

root@myopnsenserouter:~ #  file /usr/local/sbin/turbostat
/usr/local/sbin/turbostat: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 13.2, FreeBSD-style, stripped

root@myopnsenserouter:~ # uname -a
FreeBSD myopnsenserouter.mydomain.com 13.2-RELEASE-p10 FreeBSD 13.2-RELEASE-p10 stable/24.1-n254984-f7b006edfa8 SMP amd64