Bug 295941 - Minisforum MS01 instability after 7b26353a59d6 hwpstate_intel: Disable package control on hybrid CPU
Summary: Minisforum MS01 instability after 7b26353a59d6 hwpstate_intel: Disable packag...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 16.0-CURRENT
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-acpi (Nobody)
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2026-06-08 18:29 UTC by Andrew Gallatin
Modified: 2026-06-12 17:08 UTC (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Gallatin freebsd_committer freebsd_triage 2026-06-08 18:29:37 UTC
I'm opening this bug as requested by Adrian & so that others can find the bug in case the have the same problem.  I'm not asking for a reversion of the commit mentioned in the subject.

I have a Minisforum MS-01, which is basically a laptop CPU in a desktop motherboard that I use as a workstation. It is running the latest firmware (1.27).  When I first got the box last summer, I would encounter the box powering cycling as soon as I typed make -j20 buildkernel if dev.hwpstate_intel.X.epp was set lower than 44.   So I added setting those sysctls to 44 to /etc/sysctl.conf and forgot about it.

After I upgraded to a recent main version (1ee4b5fd824a fork: Drop an uneeded PHOLD/PRELE pair), the instability returned. And was present for even higher values of epp (I think I even tried 100).   I tried reverting 7b26353a59d6 and it "fixed" the problem.

I asked claude for help, and it told me about iccmax, which caps the instantaneous CPU power.  Setting this to 8*100 seems to solve my issues (it defaults to 8*210). Setting is done as:  cpucontrol -m 0x601=0x320 /dev/cpuctl0

I suspect this is something about a 110v supply on a US power brick vs a 220v supply on a Chinese power brick.

Adrian asked me to raise this issue to point out how power saving changes can have odd effects.
Comment 1 Adrian Chadd freebsd_committer freebsd_triage 2026-06-10 01:36:11 UTC
Hm, i'm not sure where we should triage this to. Do we have an x86, laptop or power management assignee to use?
Comment 2 Alexander Ziaee freebsd_committer freebsd_triage 2026-06-10 01:44:54 UTC
Triage: cc committers who have been working in that area.
Comment 3 ShengYi Hung freebsd_committer freebsd_triage 2026-06-10 14:06:24 UTC
(In reply to Andrew Gallatin from comment #0)

You are still able to set epp in this case. But currently you need to set the epp  for each core separately. Could you please check if it works for you?
Comment 4 Andrew Gallatin freebsd_committer freebsd_triage 2026-06-10 14:18:00 UTC
(In reply to ShengYi Hung from comment #3)
I'm not sure what you're asking me to try.

Again, I think my system was *ACCIDENTALLY* stable with the state of intel_hwpstate before 7b26353a59d6.  I don't think that commit was buggy

I'm actually quite happy with my current workaround, which is to set the iccmax MSR to 100 (*8), and to keep epp around 20 or so.  That prevents my box from power cycling, but gives slightly better performance in terms of buildkernel time and lets the fans get quiet when idle.  Anything below 20 seems to draw another 2j or so of power (according to Intel pcm from ports), and prevents the fans from going silent.

Eg, I think I'm actually in a better place since I stopped using epp to fix a problem it was never designed to fix.
Comment 5 ShengYi Hung freebsd_committer freebsd_triage 2026-06-10 14:24:54 UTC
(In reply to Andrew Gallatin from comment #4)

Sorry, I missed the last sentence:

"Adrian asked me to raise this issue to point out how power-saving changes can have unexpected effects."

I completely understand your point now.
Comment 6 Adrian Chadd freebsd_committer freebsd_triage 2026-06-10 14:34:36 UTC
Heh. :-)

I think we need to figure out some kernel driver layer monitoring and management of those power knobs.

Andrew, where'd you find the docs on the iccmax msr? I'd like to see what else there is and kick-start some further power management discussions for these CPU families. We should likely fix this (or at least get some documentation written!) before it shows up in other devices.
Comment 7 Andrew Gallatin freebsd_committer freebsd_triage 2026-06-10 18:32:51 UTC
(In reply to Adrian Chadd from comment #6)

In all honesty, claude told me about it as I was bouncing ideas off of it.  It seems like its not documented (checked volume 4 of the Intel SDM, where other MSRs are found), but is used in several projects.  If you do a web search for  for "PL4" or "icc_max" or intel msr 601h, you'll find about as much as I found out from claude.

This knob is typically set by BIOS and sometimes tweaked by overclockers, and i suspect its not documented because setting it wrong can lead to instability.  

Eg, for *my* case, I'm not sure there is a lot to do here.  I mostly opened this bug because you asked for it.
Comment 8 Olivier Certner freebsd_committer freebsd_triage 2026-06-12 17:05:16 UTC
(In reply to ShengYi Hung from comment #3)
But currently you need to set the epp  for each core separately. Could you please check if it works for you?

(In reply to Andrew Gallatin from comment #4)
I'm not sure what you're asking me to try.


What ShengYi is asking for is ensuring that you set EPP for all cores, with as many lines as you have cores in '/etc/sysctl.conf':
dev.hwpstate_intel.0.epp=44
dev.hwpstate_intel.1.epp=44
dev.hwpstate_intel.2.epp=44
...

If you had one line per core prior to commit 7b26353a59d6, then you should see absolutely no difference (barring a bug, and only if Intel is not cheating on us when saying that the package MSR effectively controls all cores in the package).

If you were setting, let's say, only the knob for CPU 0, then that commit indeed makes a difference (basically all cores will have the default EPP of 50% / 128).
Comment 9 Andrew Gallatin freebsd_committer freebsd_triage 2026-06-12 17:08:25 UTC
Yes, I was setting all cores to to epp=44.  So there is either a bug or a lie.

BTW, this is a horrible interface.  There should be a way to set one sysctl for all cores rather than having to write a shell script.  This is one of the things I always hated about power management on linux..