NUC15JNK (ROG NUC 2025) — ACPI storm via _L6E (not _L02) — 3030 cycles/sec captured via ETW

[xfanchx]

Hi Zephkek,

First, thank you for your deep dive — it directly led me to investigate my own system properly.

I own an ASUS ROG NUC 2025 (NUC15JNK) and I'm experiencing a persistent ACPI storm.
I followed your ETW tracing methodology and captured the events during an active storm.
The results differ from your findings on ROG laptops and I think it might be valuable
for your research.

System:

• Machine: ASUS ROG NUC 2025 (NUC15JNK) — Model: NUC15JNKU9X9 / SKU: RNUC15JNK9X28AA2
• CPU: Intel Core Ultra 9 275HX (Arrow Lake HX)
• GPU: NVIDIA RTX 5080 Laptop GPU
• BIOS: JNARL579.0031.2026.0226.1800 (EC FW 0A.17.00) — latest available
• OS: Windows 11 Pro 25H2 build 26200.8246

The symptoms:
The ACPI storm triggers after warm reboot / BIOS exit / Windows updates. Once
triggered, it does not stop on its own — LatencyMon recorded 18,730,162 ISR on
ACPI.sys after 1h52 of continuous storm with no sign of stabilization. System is
unusable for the entire duration.

There is one edge case where the storm may self-stabilize a few seconds to ~1 minute
after Windows loads — this appears to happen only when minimal peripherals are
connected (mouse and keyboard only, no Focusrite, no jack). This is not reliable
and not guaranteed.

The only working solution:
Full shutdown → unplug all peripherals AND AC power → wait 5 minutes → plug AC
back in → cold boot → plug peripherals back in once Windows is loaded.

ETW capture results (139 seconds, active storm):

• Total ACPI events: 1,262,323
• GPE method firing: _L6E exclusively — _L02 is completely absent
• Cycle rate: ~3,030 cycles/second (one cycle every ~0.33ms)
• Kernel execution time per cycle: ~10.19ms
• Loop reset pattern: 420,794 out of 421,140 "started" events have Instance ID = 0
  → The GPE is being re-triggered externally by the EC hardware on every cycle,
  not looping internally in AML

Trigger conditions:
Not yet fully characterized — storm observed after 11+ hours of normal shutdown
with all peripherals and AC power connected. The EC appears to retain state as long
as AC power is present, even with the system fully shut down.

Key difference from your findings:
Your research identified _L02 → ECLV → internal AML loop with Sleep() on ROG laptops.
On the NUC15JNK, the storm is driven by _L6E being continuously re-fired by the EC
at ~3,030 cycles/sec — a level-triggered GPE whose condition is never properly cleared.

Current BIOS situation:
ASUS fixed the _L02/ECLV bug on ROG laptops in December 2025 BIOS update.
The NUC15JNK BIOS .0031 (February 2026) does not appear to include this fix,
and the _L6E issue seems to be a separate or related bug not yet addressed.

Full ETW CSV available here

I'm also planning to extract the DSDT to read the _L6E AML method directly.

Would you be willing to take a look? Any guidance on next steps (DSDT extraction,
patch approach) would be very much appreciated.

Thanks

Full ETW CSV available
acpi2_events.zip
: https://drive.google.com/file/d/1n7GUAlqG5e4xv_CAOMieCABmzKSKfPgO/view?usp=drive_link

Thanks

[jamps3]

Current BIOS situation: ASUS fixed the _L02/ECLV bug on ROG laptops in December 2025 BIOS update. The NUC15JNK BIOS .0031 (February 2026) does not appear to include this fix, and the _L6E issue seems to be a separate or related bug not yet addressed.

Nope, newest bios for ROG GX502GW is still from 2021 version 312.
Every month there is a new problem after Windows updates, last month the touchpad shortcut toggle got broken and it took ASUS one month to fix. Now with this week update the battery charging level limit setting broke. Way to go!

[xfanchx]

Hi @Zephkek ,

Following up on this issue with an additional finding that may be relevant.

Beyond the _L6E ACPI storm, I've now identified a second firmware-level issue on the NUC15JNK: the BIOS does not set the DMA_CTRL_PLATFORM_OPT_IN_FLAG in the ACPI DMAR table.

As a result:

• Windows reports Kernel DMA Protection as disabled (msinfo32: "Protection DMA du noyau = Désactivé")
• ZwQuerySystemInformation(163) — SystemDmaProtectionInformation — returns 0
• FACEIT Anti-Cheat (which calls this exact API to verify IOMMU compliance) displays an error and prevents launching any match — the FACEIT client remains stuck on "Please launch Anti-Cheat" with no way to queue

All other security requirements are met: VT-d enabled in firmware, VBS running, HVCI enabled, Secure Boot on, TPM 2.0 ready. The sole blocker is this missing BIOS flag.

This is confirmed by inspecting FACEIT_AC.sys strings — the driver contains "Vt_D" and calls ZwQuerySystemInformation — and by scanning all accessible SystemInformationClass values, where class 163 returns 0x00 on this system.

Given your deep knowledge of ASUS NUC firmware and your contacts in that space — do you know if this flag is something that could be addressed in a BIOS update? And would you be able to relay this finding to ASUS engineering if so?

Happy to provide any additional diagnostic data.

Thank you

[xfanchx]

Hi @Zephkek

Just installed BIOS .0032 (JNARL579.0032.2026.0410.1325, EC FW 0A.19.00), published April 29th 2026. Tested using the same ETW methodology as the original report.
The _L6E storm is not fixed. The EC FW update from 0A.17.00 to 0A.19.00 has made it 3.5× worse.

BIOS	EC FW	_L6E rate	Duration	Events
.0031	0A.17.00	3,030 cycles/sec	139s	1,262,323
.0032	0A.19.00	10,609 cycles/sec	103s	1,096,485

Same ETW methodology, same trigger conditions (warm reboot with all peripherals connected). First boot after installation with minimal peripherals: ACPI.sys briefly active then self-stabilized — same edge case behavior as under .0031. The DMA_CTRL_PLATFORM_OPT_IN_FLAG issue in the ACPI DMAR table also remains unaddressed in .0032 — Kernel DMA Protection still disabled, ZwQuerySystemInformation(163) still returns 0. This is now 5 months and every available BIOS version without a fix. The EC FW team appears to be actively modifying the EC without addressing the root cause — and the latest change has made things measurably worse. ETW data .0032 (10,609 cycles/sec — 30/04/2026: Download here

ETW data .0031 (3,030 cycles/sec — 16/04/2026): Download here

[xfanchx]

Hi again @Zephkek

Update — 01/05/2026 — AML analysis + Linux hardware register investigation

Following my previous ETW reports, I have conducted a deeper investigation into the root cause of the _L6E storm, including full AML extraction, hardware register reading from Linux, and behavioral comparison between Windows and Linux ACPI handling. All commands and results are documented below.

---

1. AML extraction — tools and methodology

Tools: acpidump.exe + iasl.exe from ACPICA 20260408 (Windows binaries), run from PowerShell as administrator on Windows 11 Pro 25H2 build 26200.8246, BIOS .0032 (EC FW 0A.19.00).

powershell

cd D:\iasl-win-20260408
.\acpidump.exe -b
.\iasl.exe -d dsdt.dat
Select-String -Path "dsdt.dsl" -Pattern "_L6E" -Context 5,30

Result:

dsdt.dsl:41280:     If ((PCHA == One))
dsdt.dsl:41281:     {
dsdt.dsl:41282:         Method (_L6E, 0, NotSerialized)  // Level-Triggered GPE
dsdt.dsl:41283:         {
dsdt.dsl:41284:             ADBG ("_L6E Event")
dsdt.dsl:41285:             If (CondRefOf (\_GPE.PL6E))
dsdt.dsl:41286:             {
dsdt.dsl:41287:                 PL6E ()
dsdt.dsl:41288:             }
dsdt.dsl:41289:         }
dsdt.dsl:41290:     }

_L6E is only defined when PCHA == One. PCHA is an 8-bit field in the Global NVS region (GNVS) at fixed address 0x4E5F0000, set by the UEFI firmware before Windows loads. On this NUC15JNK, PCHA = 1 — confirmed by the existence and firing of _L6E. PCHA controls whether the secondary PCH (PC02) is present.

powershell

.\iasl.exe -d ssdt*.dat
Select-String -Path "ssdt*.dsl" -Pattern "PL6E" -Context 5,30

PL6E found in ssdt23.dsl:

ssdt23.dsl:1022:     Method (PL6E, 0, NotSerialized)
ssdt23.dsl:1023:     {
ssdt23.dsl:1024:         ADBG ("PCH L6E Start")
ssdt23.dsl:1025:         If ((\_SB.PRR2.S210 > Zero))
ssdt23.dsl:1026:         {
ssdt23.dsl:1027:             H210 ()
ssdt23.dsl:1028:         }
ssdt23.dsl:1029:
ssdt23.dsl:1030:         \_SB.PRR2.S200 = 0x4000
ssdt23.dsl:1031:     }

powershell

Select-String -Path "ssdt23.dsl" -Pattern "H210|S210|S200|PRR2" -Context 5,15

PRR2 is an ACPI Device (ssdt23.dsl line 210) mapped to a SystemIO OperationRegion PMC2 at base address ABAS (fetched from \_SB.PC02.ABAS):

asl

OperationRegion (PMC2, SystemIO, ABAS, 0xFF)
Field (PMC2, DWordAcc, Lock, Preserve)
{
    Offset (0x10),
    S210, 32,
    ...
    Offset (0x60),
    S200, 32,
    ...
}

H210 (ssdt23.dsl line 256) reads S210, checks individual bits, sends Notify(..., 0x02) (Device Wake) to PCH devices, and writes back to S210 to acknowledge each bit:

asl

Method (H210, 0, NotSerialized)
{
    Local0 = \_SB.PRR2.S210
    If ((0x20 & Local0))   { Notify (\_SB.PC02.CNVW, 0x02)  \_SB.PRR2.S210 = 0x20   }  // WiFi/CNVi
    If ((0x40 & Local0))   { Notify (\_SB.PC02.GLAN, 0x02)  \_SB.PRR2.S210 = 0x40   }  // Ethernet
    If ((0x0100 & Local0)) { Notify (\_SB.PC02.SAT0, 0x02)  \_SB.PRR2.S210 = 0x0100 }  // SATA
    If ((0x0200 & Local0)) { Notify (\_SB.PC02.XHCI, 0x02)  \_SB.PRR2.S210 = 0x0200 }  // USB
    If ((0x0400 & Local0)) { Notify (\_SB.PC02.HDAS, 0x02)  \_SB.PRR2.S210 = 0x0400 }  // HDA audio
    If ((0x1000 & Local0)) { Notify (\_SB.PC02.XDCI, 0x02)  \_SB.PRR2.S210 = 0x1000 }  // XDCI
    If ((0x4000 & Local0)) { Notify (\_SB.PC02.I3C0, 0x02)  \_SB.PRR2.S210 = 0x4000 }  // LPSS/I3C
}

---

2. PMC2 base address identification

ABAS is defined in the DSDT at line 18013 as a 16-bit field in memory region MTNV at MNVB = 0x4E629898. Its runtime value was identified via the Windows PnP device ACPI\PNP0C02\PCHRES2 (\_SB.PRR2, _UID = "PCHRES2"):

powershell

Get-PnpDevice | Where-Object {$_.HardwareId -match "PNP0C02"} | Select-Object FriendlyName, InstanceId, Status

ACPI\PNP0C02\PCHRES2   OK   (BiosDeviceName: \_SB.PRR2)

powershell

reg query "HKLM\SYSTEM\CurrentControlSet\Enum\ACPI\PNP0C02\PCHRES2\LogConf" /s

BootConfig (REG_RESOURCE_LIST):
010000000F00000000000000010001000100000001011100008C000000000000FF00000000000000

Decoded from REG_RESOURCE_LIST binary format: I/O resource Start = 0x8C00, Length = 0xFF. This is a deduction based on REG_RESOURCE_LIST binary decoding, not a directly readable value.

Therefore: ABAS = 0x8C00 (deduced), S210 at 0x8C10, S200 at 0x8C60.

---

3. Hardware register reading from Linux (Ubuntu 24.04 LTS)

To bypass Windows 11 driver restrictions (April 2026 Microsoft policy blocks all non-WHCP kernel drivers), registers were read directly from Linux using /dev/port.

Test 1 — Clean state, no Focusrite, no jack:

Peripheral configuration: DisplayPort, keyboard (ASUS ROG Falchion ACE HFX), mouse (Logitech Pro X Superlight 2, USB receiver), ethernet (RJ45 Cat6), AC power only. No Focusrite, no 3.5mm jack.

bash

sudo su
python3 -c "import struct
f = open('/dev/port', 'rb')
f.seek(0x8C10)
s210 = struct.unpack('<I', f.read(4))[0]
f.seek(0x8C60)
s200 = struct.unpack('<I', f.read(4))[0]
f.close()
print('S210:', hex(s210))
print('S200:', hex(s200))"

Result:

S210: 0x0
S200: 0x0

Test 2 — Focusrite Scarlett 2i2 3rd Gen (48V phantom power active) + 3.5mm jack connected, no storm:

bash

lsusb

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 059f:10cd LaCie, Ltd Rugged SSD
Bus 003 Device 003: ID 0b05:1b7e ASUSTek Computer, Inc. ROG FALCHION ACE HFX
Bus 003 Device 004: ID 0b05:1be5 ASUSTek Computer, Inc. ROG NUC ARGB LED Controller
Bus 003 Device 005: ID 046d:c54d Logitech, Inc. USB Receiver
Bus 003 Device 006: ID 8087:0036 Intel Corp.
Bus 003 Device 007: ID 1235:8210 Focusrite-Novation Scarlett 2i2 3rd Gen
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

bash

python3 -c "import struct
f = open('/dev/port', 'rb')
f.seek(0x8C10)
s210 = struct.unpack('<I', f.read(4))[0]
f.seek(0x8C60)
s200 = struct.unpack('<I', f.read(4))[0]
f.close()
print('S210:', hex(s210))
print('S200:', hex(s200))"

Result:

S210: 0x0
S200: 0x0

Test 3 — After confirmed Windows storm, immediate reboot to Linux without AC disconnect:

Procedure: Windows warm reboot → storm confirmed via LatencyMon:

ACPI.sys: ISR 106,415 / DPC 276,651 / Highest execution 3.350ms (43 seconds)

Peripheral configuration during this test: DisplayPort, keyboard (ASUS ROG Falchion ACE HFX), mouse (Logitech Pro X Superlight 2, USB receiver), ethernet (RJ45 Cat6), AC power, Focusrite Scarlett 2i2 3rd Gen (48V phantom power active) via OWC Thunderbolt 3 cable, Sennheiser CX300II 3.5mm jack directly on NUC. Ubuntu boot disk (SanDisk Extreme Pro) connected via USB/USB-C cable (the cable normally used for the Focusrite).

Immediate warm reboot to Ubuntu without disconnecting AC power.

bash

cat /proc/interrupts | grep -i acpi

9:  46  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  IO-APIC  9-fasteoi  acpi

bash

lsusb

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 1235:8210 Focusrite-Novation Scarlett 2i2 3rd Gen
Bus 003 Device 003: ID 059f:10cd LaCie, Ltd Rugged SSD
Bus 003 Device 004: ID 0b05:1b7e ASUSTek Computer, Inc. ROG FALCHION ACE HFX
Bus 003 Device 005: ID 0b05:1be5 ASUSTek Computer, Inc. ROG NUC ARGB LED Controller
Bus 003 Device 006: ID 046d:c54d Logitech, Inc. USB Receiver
Bus 003 Device 007: ID 8087:0036 Intel Corp.
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

bash

python3 -c "import struct
f = open('/dev/port', 'rb')
f.seek(0x8C10)
s210 = struct.unpack('<I', f.read(4))[0]
f.seek(0x8C60)
s200 = struct.unpack('<I', f.read(4))[0]
f.close()
print('S210:', hex(s210))
print('S200:', hex(s200))"

S210: 0x0
S200: 0x0

bash

while true; do
  a=$(grep "acpi" /proc/interrupts | awk '{print $2}')
  sleep 0.5
  b=$(grep "acpi" /proc/interrupts | awk '{print $2}')
  echo "ACPI IRQ/sec: $(( (b - a) * 2 ))"
done

Result: 0 IRQ/sec consistently — no storm under Linux, even immediately after a confirmed Windows storm.

---

4. Behavioral test — storm without Focusrite or jack

To determine whether the Focusrite is the storm trigger or only an aggravating factor, a warm reboot was performed with only DisplayPort, keyboard, mouse, ethernet and AC power connected — no Focusrite, no 3.5mm jack.

LatencyMon result:

ACPI.sys: ISR 15,791 / DPC 45,465 / Highest 0.996ms (at 40 seconds)

Storm triggered. After approximately 15 seconds, ISR/DPC counters froze — storm self-stabilized spontaneously.

Conclusion: the storm triggers at warm reboot regardless of Focusrite. The Focusrite prevents spontaneous stabilization by maintaining S210 non-zero via continuous USB/HDA activity (bits 0x0200 XHCI and 0x0400 HDAS in H210). Without Focusrite and without jack, S210 eventually reaches zero and the storm self-terminates. With Focusrite active, S210 never reaches zero and the storm is permanent.

---

5. Hypothesis on root cause

The complete call chain is:

_L6E  (DSDT, level-triggered GPE)
  → PL6E() (ssdt23)
      → H210() if S210 > 0   [reads S210, notifies devices, acknowledges each bit]
      → S200 = 0x4000         [supposed to clear the GPE hardware condition]

_L6E is level-triggered: it re-fires as long as the hardware GPE condition in the PMC is active. PL6E is supposed to clear this condition by writing 0x4000 into S200. The evidence suggests this write either uses the wrong bit mask for this specific Arrow Lake PCH variant, or does not clear the condition before the EC/PCH re-asserts it.

Under Linux, S210 = 0x0 and S200 = 0x0 are confirmed even immediately after a Windows storm, and ACPI IRQ rate is 0/sec. The hardware is not permanently stuck — the Windows AML handling fails to properly clear the GPE condition where the Linux ACPI driver succeeds.

The BIOS .0032 regression (10,609 cycles/sec vs 3,030 cycles/sec under .0031) was not accompanied by any visible AML change in PL6E or H210 — the regression is most likely in the EC FW 0A.19.00 behavior, which may have changed PCH wake event signaling timing in a way that makes the S200 = 0x4000 acknowledgement even less effective.

---

6. ETW data

BIOS | EC FW | _L6E rate | Duration | Events -- | -- | -- | -- | -- .0031 | 0A.17.00 | 3,030 cycles/sec | 139s | 1,262,323 .0032 | 0A.19.00 | 10,609 cycles/sec | 103s | 1,096,485

ETW data .0032 (10,609 cycles/sec — 30/04/2026): <a href="https://drive.google.com/file/d/1fvhWsk6-xY6MKtTy-bfWbKaV3KMxI27_/view?usp=drive_link">Download here</a>

ETW data .0031 (3,030 cycles/sec — 16/04/2026): https://drive.google.com/file/d/1n7GUAlqG5e4xv_CAOMieCABmzKSKfPgO/view?usp=drive_link

---

7. Open questions

Two things remain unresolved without access to the Arrow Lake PCH datasheet:

• Is S200 = 0x4000 the correct acknowledgement value for GPE _L6E on this specific Arrow Lake PCH variant?
• What does the Linux ACPI driver do differently when handling _L6E that allows it to clear the condition where the Windows AML fails?

Any guidance on the correct S200 acknowledgement sequence for Arrow Lake PCH GPE handling would be extremely valuable.