Couple additional details. Changing hw.perfpolicy from high to auto and
back to high has a distinct side-effect. By default, perfpolicy_on_ac=high
and perfpolicy_on_battery=auto. Specifying auto/high (rather than
auto,auto/high,auto) changed both ac/battery perf-policy to high. This has
a profound impact on how kern/sched_bsd.c:setperf_auto() operates.

On a default install, even on a non-laptop w/o battery, setperf_auto()
gets called every 100ms via timer which calls cpu_setperf(100) which calls
mp_setperf(level) which uses x86_broadcast_ipi(X86_IPI_SETPERF). This
means every CPU core gets either brought out of power-savings or a running
task is interrupted. Worse, its all for nothing because aside for a short
period during boot, the cores are already at 100%.

Am wondering if I actually have a power issue. When all cores but one are
in deepest C-state and X86_IPI_SETPERF broadcast causes synchronized wakeup
of all those core to max frequency, could see that stressing the voltage
rail a bit. Rolling the dice every 100ms and maybe the other factor of a 
packet arriving so that the PHY needs a bit more power at the wrong time.

On Monday, January 19th, 2026 at 2:43 PM, Greg Schaefer <gsgs7878@proton.me> wrote:

> Have an odd situation with a Intel 125H based NUC with I226-LM+I226-V.
> Typically 30s-60m post-boot with a light load, igc0/i226-LM stops
> receiving packets while igc1/i226-V operates fine. igc0 can still send
> but its rx-err/rx-crc counters tick up. After down/up link, the issue
> reoccurs after another 30s-60m period.
> 
> Initially though it was one of the numerous i225/i226 issues, but
> these are V4 chips with later V2.22 firmware. Disabling C-states >C1
> 
> (whether via the BIOS or hacking acpicpu_x86.c) avoids the issue at the
> cost of high power consumption. Other purported i226 workarounds like
> disabling ASPM had no effect.
> 
> The problem does not occur with basic Linux or FreeBSD test installs.
> 
> While experimenting, found that changing hw.perfpolicy from high to
> auto and back to high fixed the issue. Feels like the BIOS or some
> other embedded power management firmware is triggering power savings
> because it thinks OpenBSD cannot. Active frequency management via
> MSR_PERF_CTL / hw.perfpolicy=auto (even for a short time) seems to
> disable the mystery power saver.
> 
> Modifying amd64/est.c/est_init() and amd64/cpu.c/cpu_hatch() to each
> call est_setperf(perflevel=99) (setting an initial frequency for each
> core as they come online) combined with kern/sched_bsd.c/setperf_auto()
> firing (and refiring...) 200ms later also seems to do the trick.
> 
> Am certain there is a more precise explanation and would welcome any
> thoughts. Thanks.