I started having an issue when I enabled powerd on FreeBSD 12.2. With the default adaptive settings, the system would hard reset shortly after starting the daemon. After some digging it seems that it this reset occurs when the frequency is set and is instantly reproduceable with sysctl: nas: ~# sysctl dev.cpu.0.freq dev.cpu.0.freq: 3400 nas: ~# sysctl -n dev.cpu.0.freq_levels 3400/3867 2975/3383 2800/2537 2450/2219 2100/1902 1750/1585 1550/1237 1356/1082 1162/927 968/773 775/618 581/463 387/309 193/154 nas: ~# sysctl dev.cpu.0.freq=2100 dev.cpu.0.freq: 3400 -> 2100 nas: ~# *reset* I am running the following configuration: ASUS PRIME A320I-K Ryzen 2600 Corsair 2x8GB 2666MHz SilverStone 650W SFX Power Supply 4x8TB WD Red Asus BIOS update latest version 2203 - 2020/08/11 (AGESA at 1006). I have updated to FreeBSD 12.2-RELEASE-p3 (from a fresh install of RELEASE) as well. After some searching, I also tried the following BIOS tricks and they don't change the symptom: Global C-State Control - Disabled Power Supply Idle Control - Typical SMT - Disabled I did run up an Ubuntu instance and frequency scaling is working and reporting correctly on there (under /proc/cpuinfo). Interestingly the FreeBSD system reports 22.5W at idle with just CPU/RAM/Motherboard/Fans/USB/No Graphics Card (but the CPU still reporting 2400MHz) and the same could be seen under Ubuntu. Something else of interest is that with this config, temp monitoring reports incorrect temperatures (same as board temp in BIOS, CPU temp is about 10 degrees more): dev.cpu.11.temperature: 32.1C dev.cpu.10.temperature: 32.1C dev.cpu.9.temperature: 32.1C dev.cpu.8.temperature: 32.1C dev.cpu.7.temperature: 32.1C dev.cpu.6.temperature: 32.1C dev.cpu.5.temperature: 32.1C dev.cpu.4.temperature: 32.1C dev.cpu.3.temperature: 32.1C dev.cpu.2.temperature: 32.1C dev.cpu.1.temperature: 32.1C dev.cpu.0.temperature: 32.1C Could it be that the CPU is actually scaling correctly without powerd and just not reporting? Anyway, that's a bit of an aside, the hard reboot is the main problem.
Oh just to add, this is reported in dmesg: acpi_throttle0: <ACPI CPU Throttling> on cpu0 hwpstate0: <Cool`n'Quiet 2.0> on cpu0 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 acpi_throttle2: failed to attach P_CNT device_attach: acpi_throttle2 attach returned 6 acpi_throttle3: failed to attach P_CNT device_attach: acpi_throttle3 attach returned 6 acpi_throttle4: failed to attach P_CNT device_attach: acpi_throttle4 attach returned 6 acpi_throttle5: failed to attach P_CNT device_attach: acpi_throttle5 attach returned 6 acpi_throttle6: failed to attach P_CNT device_attach: acpi_throttle6 attach returned 6 acpi_throttle7: failed to attach P_CNT device_attach: acpi_throttle7 attach returned 6 acpi_throttle8: failed to attach P_CNT device_attach: acpi_throttle8 attach returned 6 acpi_throttle9: failed to attach P_CNT device_attach: acpi_throttle9 attach returned 6 acpi_throttle10: failed to attach P_CNT device_attach: acpi_throttle10 attach returned 6 acpi_throttle11: failed to attach P_CNT device_attach: acpi_throttle11 attach returned 6 Also the system is rock solid without powerd enabled and the system is running all the stock speeds.
Re: low idle power without powerd: most idle power-saving of Zen and newer CPUs comes from entering C-states (which FreeBSD does automatically), rather than lower-frequency P-states. So, I don't know why the pstate-setting stuff doesn't work. But I wouldn't worry too much about just disabling powerd.
See possibly related bug 221621, bug 218262.
Ah well that makes sense as to why the power usage is still low. Good to know that powerd really isn't really needed here for this Ryzen setup. I can live happy knowing it's not just chewing power away like a dog eating styrofoam blocks, but I'm happy to perform any tests if need be and report back. Bit concerning that setting the frequency causes a reset like that though, it makes things super hard to debug. I did try with microcode updates enabled as well after updating the BIOS (and made sure microcode_amd_fam17h.bin exists too), but it doesn't report that it updated anything and the problem persists. There isn't any other concerning errors in the logs at all to indicate a problem.