I run OpenBSD 7.9 on a Librem 14 (i7-10710U, 6c/12t, 15W) and spent the last few days trying to figure out why my CPU never seems to leave base clock under sustained load. Wanted to share what I found, partly because I'd like a sanity check on the diagnosis, and partly in case someone has thoughts on whether there's a small fix worth attempting.
Under any sustained all-core workload, hw.cpuspeed reports 1101 MHz and stays there (this might be a cosmetic issue of hw.cpuspeed). apmd -A, apmd -H, and obsdfreqd all produce identical wall-clock benchmark times within ~1%. The same hardware on GNU/Linux turbos to ~2.2 GHz all-core and ~4 GHz single-core under the same loads. My dmesg shows acpicpu0 at acpi0: ..., PSS rather than the FVS line — reading acpicpu_x86.c, that's because _PCT uses FFixedHW addressing, which trips the goto in acpicpu_getpct. So acpicpu drops out of setperf duty and est(4) takes over. I dumped the ACPI tables and looked at _PSS. The first entry decodes to: CoreFreq: 1101 MHz, Control: 0x2F00 (ratio 47 = 4700 MHz) That's the standard "Pseudo-P0" turbo convention — base+1 as the marker frequency, Control encodes max turbo ratio. The other five entries are the actual non-turbo P-states (1100, 1000, 800, 600, 400). Reading est.c (via the github mirror), est_acpi_pss_changed copies pss_ctrl straight into its operating points table, so est would write 0x2F00 to MSR_IA32_PERF_CTL when setperf=100. I booted a Debian GNU/Linux live USB to read MSRs: 0x770 (PM_ENABLE): 1 0x1AD (TURBO_RATIO_LIMIT): 0x2727272729292F2F 0x1A0 (MISC_ENABLE) bit 38: 0 0xCE (PLATFORM_INFO): max non-turbo ratio = 11 HWP is enabled by Purism's coreboot at boot. Per the SDM, that means PERF_CTL writes don't actually affect the chip's frequency — IA32_HWP_REQUEST (0x774) is what matters. With no OS-side HWP support, nothing's writing meaningful values there, so the chip sits in whatever state HWP defaults to, which on this platform happens to be base clock under load. So as far as I can tell: the est driver does the right thing with the Pseudo-P0 Control value, but the write is functionally a no-op while HWP is on. A couple of questions for anyone who knows this area better than I do: Is there in-progress HWP work I should know about? jcs mentioned a shim in 2021 (https://jcs.org/2021/01/27/x1nano), but I don't see signs it landed. Is the obvious-sounding minimal fix — detect HWP at boot, write a reasonable max-perf value to HWP_REQUEST per CPU, treat est's setperf as a no-op when HWP is on — actually as simple as it sounds, or are there suspend/resume / per-package / EPP-policy gotchas that make it worse than I think? The other alternative is to just rebuild coreboot from source with HWP disabled. Happy to share the full DSDT/SSDT dumps and dmesg if useful. The Librem 14 coreboot also exposes _CPC properly. Thanks, Thomas
