From: Greg Schaefer Subject: Re: igc0 going offline w/default perfpolicy To: Greg Schaefer Cc: "tech@openbsd.org" Date: Mon, 19 Jan 2026 23:43:20 +0000 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 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.