Issue #657 has been updated by Sebastian Müller.
Hit one of these on a sibling ADL-N board with the same IT8625E Super-I/O. This
also looks like the "broken IRQ 9" in #631, and I think it explains why the
GPIO patch there did not help: it is not GPIO.
IRQ9 / SCI storm. topton/adl/devicetree.cb declares only the IT8625E COM1 LDN,
not the Environment Controller / HWM LDN (2e.4). coreboot auto-creates an
undeclared Super-I/O LDN as enabled (device.c __alloc_dev sets enabled=1) and
activates it, but with no irq 0x70 in the devicetree it never writes the HWM's
IRQ register, so that register keeps its power-on default = IRQ9 = the SCI
line. On a fanless box the empty CPU-fan header makes the HWM raise a permanent
fan-fault, which then storms IRQ9 over the eSPI virtual wire with no GPE/PM1
status to ack, so the kernel masks it ("nobody cared"). The stock firmware
keeps the HWM off the SCI.
Quick check on the running board:
superiotool -d # LDN 0x04 (EC): is it active, and is reg 0x70 = 09?
Fix is to declare the HWM LDN and force no IRQ (keeps the sensors, off the SCI):
device pnp 2e.4 on # Environment Controller (HWM)
io 0x60 = 0xa30 # take the bases from your superiotool -d
io 0x62 = 0xa20
irq 0x70 = 0x00 # HWM off IRQ9 (= the SCI), matches stock
end
IRQ4 / UART0 storm is separate and is not a coreboot bug. coreboot hands the
3f8 UART to the OS with all interrupts disabled (uart8250io.c writes IER=0).
FreeBSD's ns8250 then enables modem-status interrupts (IER_EMSC) by default; on
the "Cisco-style" RJ45 console the RS232 handshake inputs (CTS/DSR/DCD/RI) are
unconnected and float, so their status-change deltas storm IRQ4.
hint.uart.0.disabled="1" is a correct fix if you do not use that port. To keep
the serial console but kill the storm, drop only modem-status interrupts:
hint.uart.0.ier_rxbits="0x05" # IER_ERLS|IER_ERXRDY, no IER_EMSC
(The IT8625E serial reg 0xF0=1 = IRQ-sharing mode is not implicated; the
non-storming sibling uses the same value.)
cc @Alicja as topton/adl maintainer, and re #631.
----------------------------------------
Bug #657: Alder Lake (x2e_n150) ACPI SCI (IRQ9) Interrupt Storm Escalation up
to 180k/sec on FreeBSD/OPNsense
https://ticket.coreboot.org/issues/657#change-2340
* Author: Zoomm Deka
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2026-07-10
* Affected versions: main
----------------------------------------
Following up on the initial observation of interrupt storms on an Intel Alder
Lake platform (x2e_n150 mainboard) running FreeBSD 14 / OPNsense 26.7 with a
clean Libreboot/coreboot image:
UART0 (IRQ4): Disabling the serial port via loader hints
(hint.uart.0.disabled="1") successfully stopped the IRQ4 storm.
ACPI SCI (IRQ9): The ACPI storm on IRQ9 escalated drastically post-boot,
reaching a critical rate of 181,199 interrupts per second. Attempts to mitigate
this via software (e.g., changing the trigger to edge mode using
hw.acpi.sci.trigger="edge") were unsuccessful, indicating a persistent
level-triggered assertion from the hardware/firmware side.
This storm consumes significant CPU cycles, causing system degradation and
immediate hard locks when USB devices or higher IO loads are introduced.
Updated Data from vmstat -i:
interrupt total rate
irq9: acpi0 4241009125 181199
Context & Platform Details:
Mainboard: x2e_n150 (Intel Alder Lake)
OS: FreeBSD 14.1-RELEASE / OPNsense 26.7
Firmware: Clean Libreboot/coreboot compilation (includes commit 4988900789
soc/intel/alderlake: Fix PCI IRQ tables).
The issue points to an unhandled GPE (General Purpose Event) loop or incorrect
SCI routing configuration within the Alder Lake ACPI implementation for this
specific board variant.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
https://ticket.coreboot.org/my/account
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
