Project

General

Profile

Actions

Bug #657

open
ZD

Alder Lake (x2e_n150) ACPI SCI (IRQ9) Interrupt Storm Escalation up to 180k/sec on FreeBSD/OPNsense

Bug #657: Alder Lake (x2e_n150) ACPI SCI (IRQ9) Interrupt Storm Escalation up to 180k/sec on FreeBSD/OPNsense

Added by Zoomm Deka 4 days ago. Updated 4 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
07/10/2026
Due date:
% Done:

0%

Estimated time:
Affected versions:
Needs backport to:
Affected hardware:
Affected OS:

Description

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.

ZD Updated by Zoomm Deka 4 days ago Actions #1

  • Description updated (diff)

SM Updated by Sebastian Müller 4 days ago · Edited Actions #2

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.)

Re the gpio.patch from ellyq in #631: on my sibling ADL-N board the same IRQ 9 turned out to be not GPIO but the IT8625E HWM on its default SCI IRQ, so a GPIO-only change would not settle it on topton either.

SM Updated by Sebastian Müller 4 days ago Actions #3

Pushed the fix to Gerrit (in the shared topton/adl devicetree, so it covers
the x2e_n150):

https://review.coreboot.org/c/coreboot/+/94028

Could you build master with it and confirm the IRQ 9 storm is gone on
FreeBSD/OPNsense? If it holds up I'll note it here.

ZD Updated by Zoomm Deka 4 days ago · Edited Actions #4

Sebastian Müller wrote in #note-3:

Pushed the fix to Gerrit (in the shared topton/adl devicetree, so it covers
the x2e_n150):

https://review.coreboot.org/c/coreboot/+/94028

Could you build master with it and confirm the IRQ 9 storm is gone on
FreeBSD/OPNsense? If it holds up I'll note it here.

Thanks, Sebastian. The initial test with the same change already improved the system significantly, and the IRQ9 storm appears to be gone. I am now building and testing your exact Gerrit patch, and I will report back once I complete the remaining checks with superiotool, dmesg, and vmstat -i.

Confirmed on the x2e_n150 after flashing the build with Gerrit change 94028. OPNsense boots normally and vmstat -i shows no IRQ9/SCI storm.

Separately, hint.uart.0.ier_rxbits="0x05" reduced the FreeBSD UART0 storm from about 9,956 interrupts/s (2,027,625 total) to about 21 interrupts/s (735 total).

Actions

Also available in: PDF Atom