On Wed, May 20, 2026 at 11:36:47AM -0400, Thomas Vetere wrote: > 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 >
an acpidump might be helpful here. man sendbug
