Zephkek/Asus-ROG-Aml-Deep-Dive: A deep dive into the ACPI.sys DPC latency issues on Asus ROG laptops

You personal a high-end ASUS ROG laptop computer maybe a Strix, Scar, or Zephyrus. It’s specs are spectacular: an RTX 30/40 sequence GPU, a top-tier Intel processor, and loads of RAM. Yet, it stutters throughout primary duties like watching a YouTube video, audio crackles and pops on Discord calls, the mouse cursor freezes for a break up second, simply lengthy sufficient to be infuriating.

You’ve seemingly tried all the standard fixes:

• Updating each driver conceivable, a number of instances.
• Performing a “clean” reinstallation of Windows.
• Disabling each conceivable power-saving possibility.
• Manually tweaking processor interrupt affinities.
• Following convoluted multi-step guides from Reddit threads.
• Even putting in Linux, solely to seek out the issue persists.

If none of that labored, it is as a result of the problem is not with the working system or a driver. The downside is way deeper, embedded within the machine’s firmware, the BIOS.

The first software in any efficiency investigator’s toolkit for these signs is LatencyMon. It acts as a canary within the coal mine for system-wide latency points. On an affected ASUS Zephyrus M16, the outcomes are instant and damning:

CONCLUSION
Your system seems to be having hassle dealing with real-time audio and different duties. 
You are prone to expertise buffer underruns showing as drop outs, clicks or pops.

HIGHEST MEASURED INTERRUPT TO PROCESS LATENCY
Highest measured interrupt to course of latency (μs):   65,816.60
Average measured interrupt to course of latency (μs):   23.29

HIGHEST REPORTED ISR ROUTINE EXECUTION TIME
Highest ISR routine execution time (μs):              536.80
Driver with highest ISR routine execution time:       ACPI.sys

HIGHEST REPORTED DPC ROUTINE EXECUTION TIME  
Highest DPC routine execution time (μs):              5,998.83
Driver with highest DPC routine execution time:       ACPI.sys

The knowledge clearly implicates ACPI.sys. However, the per-CPU knowledge reveals a extra particular sample:

CPU 0 Interrupt cycle time (s):                       208.470124
CPU 0 ISR highest execution time (μs):                536.804674
CPU 0 DPC highest execution time (μs):                5,998.834725
CPU 0 DPC whole execution time (s):                   90.558238

CPU 0 is taking the brunt of the impression, spending over 90 seconds processing interrupts whereas different cores stay largely unaffected. This is not a failure of load balancing; it is a course of locked to a single core.

The same check on a Scar 15 from 2022 exhibits the very same perpetrator: excessive DPC latency originating from ACPI.sys.

It’s straightforward accountable a Windows driver, however ACPI.sys shouldn’t be a typical driver. It primarily capabilities as an interpreter for ACPI Machine Language (AML), the code supplied by the laptop computer’s firmware (BIOS). If ACPI.sys is sluggish, it is as a result of the firmware is feeding it inefficient or flawed AML code to execute. These slowdowns are sometimes triggered by General Purpose Events (GPEs) and visitors from the Embedded Controller (EC). To discover the true supply, we should dig deeper.

To perceive what ACPI.sys is doing throughout these latency spikes, we will use Event Tracing for Windows (ETW) to seize detailed logs from the ACPI suppliers.

# Find the related ACPI ETW suppliers
logman question suppliers | findstr /i acpi
# This returns two key suppliers:
# Microsoft-Windows-Kernel-Acpi {C514638F-7723-485B-BCFC-96565D735D4A}
# Microsoft-ACPI-Provider {DAB01D4D-2D48-477D-B1C3-DAAD0CE6F06B}

# Start a complete hint session
logman begin ACPITrace -p {DAB01D4D-2D48-477D-B1C3-DAAD0CE6F06B} 0xFFFFFFFF 5 -o C:Tempacpi.etl -ets
logman replace ACPITrace -p {C514638F-7723-485B-BCFC-96565D735D4A} 0xFFFFFFFF 5 -ets

# Then as soon as we're performed we will cease the hint and examine the etl file and save the information in csv format aswell.
logman cease ACPITrace -ets
tracerpt C:Tempacpi.etl -o C:Tempacpi_events.csv -of CSV

Analyzing the ensuing hint file within the Windows Performance Analyzer reveals an important perception. The spikes aren’t random; they’re periodic, occurring like clockwork each 30 to 60 seconds.

Random interruptions typically recommend {hardware} faults or thermal throttling. A wonderfully repeating sample factors to a systemic situation, a timer or a scheduled occasion baked into the system’s logic.

The uncooked occasion knowledge confirms this sample:

Clock-Time (100ns),        Event,                      Kernel(ms), CPU
134024027290917802,       _GPE._L02 began,          13.613820,  0
134024027290927629,       _SB...BAT0._STA began,    0.000000,   4
134024027290932512,       _GPE._L02 completed,         -,          6

The first occasion, _GPE._L02, is an interrupt handler that takes 13.6 milliseconds to execute. For a high-priority interrupt, that is an eternity and is catastrophic for real-time system efficiency.

Deeper within the hint, one other weird conduct emerges; the system repeatedly makes an attempt to energy the discrete GPU on and off, even when it is imagined to be completely lively.

Clock-Time,                Event,                    Duration
134024027315051227,       _SB.PC00.GFX0._PS0 begin, 278μs     # GPU Power On
134024027315155404,       _SB.PC00.GFX0._DOS begin, 894μs     # Display Output Switch
134024027330733719,       _SB.PC00.GFX0._PS3 begin, 1364μs    # GPU Power Off
[~15 seconds later]
134024027607550064,       _SB.PC00.GFX0._PS0 begin, 439μs     # Power On Again!
134024027607657368,       _SB.PC00.GFX0._DOS begin, 1079μs    # Display Output Switch
134024027623134006,       _SB.PC00.GFX0._PS3 begin, 394μs     # Power Off Again!
...

This energy biking is nonsensical as a result of the laptop computer is configured for a situation the place it’s not possible: The system is in Ultimate Mode (through a MUX change) with an exterior show linked.

In this mode:

• The discrete NVIDIA GPU (dGPU) is the solely lively graphics processor.
• The built-in Intel GPU (iGPU) is totally powered down and bypassed.
• The dGPU is wired on to the interior and exterior shows.
• There isn’t any mechanism for switching between GPUs.

Yet, the firmware ignores MUX state nudging the iGPU path (GFX0) and, worse, partaking dGPU reduce/notify logic (PEGP/PEPD) each 15–30 seconds. The dGPU in mux mode is not simply “preferred” – it is the ONLY path to the show. There’s no fallback, and no different. When the firmware sends _PS3 (energy off), it is making an attempt one thing architecturally not possible.

Most of the time, {hardware} sanity checks refuse these nonsensical instructions, however even failed makes an attempt introduce latency spikes inflicting audio dropouts, enter lag, and accumulating efficiency degradation. Games freeze mid-session, movies buffer indefinitely, system responsiveness deteriorates till restart.

Sometimes, underneath particular thermal situations or race situations, the power-down really succeeds. When the firmware manages to energy down the GPU that is driving the show, the sequence is predictable and catastrophic:

1. Firmware OFF try – cuts the dgpu path through PEG1.DGCE
2. Hardware complies – security checks fail or timing aligns
3. Display sign cuts – screens go black
4. User enter triggers wake – mouse/keyboard exercise
5. Windows calls PowerOnMonitor() – try show restoration
6. NVIDIA driver executes _PS0 – GPU energy on command
7. GPU enters not possible state – firmware insists OFF, Windows wants ON
8. Driver thread blocks indefinitely – ready for GPU response
9. 30-second watchdog expires – Windows offers up
10. System crashes with BSOD

5: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

WIN32K_POWER_WATCHDOG_TIMEOUT (19c)
Win32k didn't flip the monitor on in a well timed method.
Arguments:
Arg1: 0000000000000050, Calling monitor driver to energy on.
Arg2: ffff8685b1463080, Pointer to the facility request employee thread.
Arg3: 0000000000000000
Arg4: 0000000000000000
...
STACK_TEXT:  
fffff685`3a767130 fffff800`94767be0     : 00000000`00000047 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSwapContext+0x76
fffff685`3a767270 fffff800`94726051     : ffff8685`b1463080 00000027`00008b94 fffff685`3a767458 fffff800`00000000 : nt!KiSwapThread+0x6a0
fffff685`3a767340 fffff800`94724ed3     : fffff685`00000000 00000000`00000043 00000000`00000002 0000008a`fbf50968 : nt!KiCommitThreadWait+0x271
fffff685`3a7673e0 fffff800`9471baf2     : fffff685`3a7675d0 02000000`0000001b 00000000`00000000 fffff800`94724500 : nt!KeWaitForSingleObject+0x773
fffff685`3a7674d0 fffff800`9471b7d5     : ffff8685`9cbec810 fffff685`3a7675b8 00000000`00010224 fffff800`00000003 : nt!ExpWaitForFastResource+0x92
fffff685`3a767580 fffff800`9471b49d     : 00000000`00000000 ffff8685`9cbec850 ffff8685`b1463080 00000000`00000000 : nt!ExpAcquireFastResourceExclusiveSlow+0x1e5
fffff685`3a767630 fffff800`28faca9b     : fffff800`262ee9c8 00000000`00000003 ffff8685`9cbec810 02000000`00000065 : nt!ExAcquireFastResourceExclusive+0x1bd
fffff685`3a767690 fffff800`28facbe5     : ffff8685`b31de000 00000000`00000000 ffffd31d`9a05244f 00000000`00000000 : win32kbase!::+0x2b
fffff685`3a7676c0 fffff800`28e5f864     : ffffad0c`94d10878 fffff685`3a767769 ffffad0c`94d10830 ffff8685`b31de000 : win32kbase!UserCritInternal::`nameless namespace'::EnterCritInternalEx+0x4d
fffff685`3a7676f0 fffff800`28e5f4ef     : 00000000`00000000 00000000`00000000 fffff800`262ee9c8 00000000`00000000 : win32kbase!DrvSetWddmDeviceMonitorPowerState+0x354
fffff685`3a7677d0 fffff800`28e2abab     : ffff8685`b31de000 00000000`00000000 ffff8685`b31de000 00000000`00000000 : win32kbase!DrvSetMonitorPowerState+0x2f
fffff685`3a767800 fffff800`28ef22fa     : 00000000`00000000 fffff685`3a7678d9 00000000`00000001 00000000`00000001 : win32kbase!PowerOnMonitor+0x19b
fffff685`3a767870 fffff800`28ef13dd     : ffff8685`94a40700 ffff8685`a2eb31d0 00000000`00000001 00000000`00000020 : win32kbase!xxxUserPowerEventCalloutWorker+0xaaa
fffff685`3a767940 fffff800`4bab21c2     : ffff8685`b1463080 fffff685`3a767aa0 00000000`00000000 00000000`00000020 : win32kbase!xxxUserPowerCalloutWorker+0x13d
fffff685`3a7679c0 fffff800`26217f3a     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : win32kfull!NtUserUserPowerCalloutWorker+0x22
fffff685`3a7679f0 fffff800`94ab8d55     : 00000000`000005bc 00000000`00000104 ffff8685`b1463080 00000000`00000000 : win32k!NtUserUserPowerCalloutWorker+0x2e
fffff685`3a767a20 00007ff8`ee71ca24     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x25
000000cc`d11ffbc8 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ff8`ee71ca24

...

The crash dump confirms the thread is caught in win32kbase!DrvSetWddmDeviceMonitorPowerState, ready for the NVIDIA driver to reply. It cannot as a result of it is caught between a confused energy state, home windows desirous to activate the GPU whereas the firmware is arming the GPU reduce off.

GPEs are the firmware’s mechanism for signaling {hardware} occasions to the working system. They are primarily {hardware} interrupts that set off the execution of ACPI code. The hint knowledge factors squarely at _GPE._L02 because the supply of our latency.

A more in-depth have a look at the timing reveals a constant and problematic sample:

_GPE._L02 Event Analysis from ROG Strix Trace:

Event 1 @ Clock 134024027290917802
  Duration: 13,613,820 ns (13.61ms)
  Triggered: Battery and AC adapter standing checks

Event 2 @ Clock 134024027654496591  
  Duration: 13,647,255 ns (13.65ms)
  Triggered: Battery and AC adapter standing checks
  
Event 3 @ Clock 134024028048493318
  Duration: 13,684,515 ns (13.68ms)  
  Triggered: Battery and AC adapter standing checks

Interval between occasions: ~36-39 seconds
Consistency: The period is remarkably secure and the interval is periodic.

Every single time the prolonged _GPE._L02 occasion fires, it triggers the very same sequence of ACPI technique calls.

The sample is simple:

1. A {hardware} interrupt fires _GPE._L02.
2. The handler executes strategies to examine battery standing.
3. Shortly thereafter, the firmware makes an attempt to vary the GPU’s energy state.
4. The system runs usually for about 30-60 seconds.
5. The cycle repeats.

To analyze the code answerable for this conduct, we should extract and decompile the ACPI tables supplied by the BIOS to the working system.

# Extract all ACPI tables into binary .dat information
acpidump -b

# Output consists of:
# DSDT.dat - The predominant Differentiated System Description Table
# SSDT1.dat ... SSDT17.dat - Secondary System Description Tables

# Decompile the primary desk into human-readable ACPI Source Language (.dsl)
iasl -d DSDT.dsl

This decompiled ASL offers a direct view into the firmware’s executable logic. It is a exact illustration of the precise directions that the ACPI.sys driver is fed by the firmware and executes on the highest privilege degree throughout the Windows kernel. Any logical flaws discovered on this code are the direct reason for the system’s conduct.

Searching the decompiled DSDT.dsl file, we discover the definition for our problematic GPE handler:

Scope (_GPE)
{
    Method (_L02, 0, NotSerialized)  // _Lxx: Level-Triggered GPE
    {
        _SB.PC00.LPCB.ECLV ()
    }
}

This code is straightforward: when the _L02 interrupt happens, it calls a single technique, ECLV. The “L” prefix in _L02 signifies that this can be a level-triggered interrupt, which means it’s going to proceed to fireplace so long as the underlying {hardware} situation is lively. This is a essential element.

Following the decision to ECLV(), we uncover a deeply flawed implementation that’s the direct reason for the system-wide stuttering.

Method (ECLV, 0, NotSerialized)  // Starting at line 099244
{
    // Main loop - continues whereas occasions exist OR sleep occasions are pending
    // AND we have not exceeded our time price range (TI3S < 0x78)
    While (((CKEV() != Zero) || (SLEC != Zero)) && (TI3S < 0x78))
    {
        Local1 = One
        While (Local1 != Zero)
        {
            Local1 = GEVT()    // Get subsequent occasion from queue
            LEVN (Local1)      // Process the occasion
            TIMC += 0x19       // Increment time counter by 25
            
            // This is the place it will get actually unhealthy
            If ((SLEC != Zero) && (Local1 == Zero))
            {
                // No occasions however sleep occasions pending
                If (TIMC == 0x19)
                {
                    Sleep (0x64)    // Sleep for 100 milliseconds!!!
                    TIMC = 0x64     // Set time counter to 100
                    TI3S += 0x04    // Increment main counter by 4
                }
                Else
                {
                    Sleep (0x19)    // Sleep for 25 milliseconds!!!
                    TI3S++          // Increment main counter by 1
                }
            }
        }
    }
    
    // Here's the place it will get even worse
    If (TI3S >= 0x78)  // If we hit our time price range (120)
    {
        TI3S = Zero
        If (EEV0 == Zero)
        {
            EEV0 = 0xFF    // Force one other occasion to be pending!
        }
    }
}

This brief block of code violates a number of basic rules of firmware and kernel programming.

Wtf 1: Sleeping in an Interrupt Context

Sleep (0x64)    // 100ms sleep
Sleep (0x19)    // 25ms sleep

An interrupt handler runs at a really excessive precedence to service {hardware} requests rapidly. The Sleep() operate utterly halts the execution of the CPU core it’s working on (CPU 0 on this case). While CPU 0 is sleeping, it can’t:

• Process some other {hardware} interrupts.
• Allow the kernel to schedule different threads.
• Update system timers.

Clarification: These Sleep() calls stay within the ACPI GPE dealing with path for the GPE L02, these calls get executed at PASSIVE_LEVEL after the SCI/GPE is acknowledged so it is not a uncooked ISR (as a result of i do not assume home windows will even permit that) however analyzing this additional whereas the management technique runs the GPE stays masked and the ACPI/EC work is serialized. With the Sleep() calls inside that path and the self rearm it appears to have the impact of creating ACPI.sys get tied up in lengthy periodic bursts (typically on CPU 0) which nonetheless have the identical impact on the system.

Wtf 2: Time-Sliced Interrupt Processing
The whole loop is designed to run for an prolonged interval, processing occasions in batches. It’s successfully a poorly designed process scheduler working inside an interrupt handler, able to holding a CPU core hostage for probably seconds at a time.

Wtf 3: Self-Rearming Interrupt

If (EEV0 == Zero)
{
    EEV0 = 0xFF    // Forces all EC occasion bits on
}

This logic ensures that even when the Embedded Controller’s occasion queue is empty, the code will create a brand new, synthetic occasion. This ensures that one other interrupt will fireplace shortly after, creating the peerlessly periodic sample of ACPI spikes noticed within the traces.

The LEVN() technique takes an occasion and routes it:

Method (LEVN, 1, NotSerialized)
  {
      If ((Arg0 != Zero))
      {
          MBF0 = Arg0
          P80B = Arg0
          Local6 = Match (LEGA, MEQ, Arg0, MTR, Zero, Zero)
          If ((Local6 != Ones))
          {
              LGPA (Local6)
          }
      }
  }

The LGPA() technique is a big change assertion dealing with completely different occasions:

Method (LGPA, 1, Serialized)  // Line 098862
{
    Switch (ToInteger (Arg0))
    {
        Case (Zero)  // Most widespread case - energy occasion
        {
            DGD2 ()       // GPU-related operate
            ^EC0._QA0 ()  // EC question technique
            PWCG ()       // Power change - that is our battery polling
        }
        
        Case (0x18)  // GPU-specific occasion
        {
            If (M6EF == One)
            {
                Local0 = 0xD2
            }
            Else
            {
                Local0 = 0xD1
            }
            NOD2 (Local0)  // Notify GPU driver
        }
        
        Case (0x1E)  // Another GPU occasion
        {
            Notify (^^PEG1.PEGP, 0xD5)  // Direct GPU notification
            ROCT = 0x55                  // Sets flag for follow-up
        }
       
    }
}

This exhibits a direct hyperlink: a GPE fires, and the dispatch logic calls capabilities associated to battery polling and GPU notifications.

The PWCG() technique, known as by a number of occasion varieties, is answerable for polling the battery and AC adapter standing.

Method (PWCG, 0, NotSerialized)
{
    Notify (ADP0, Zero)      // Tell OS to examine the AC adapter
    ^BAT0._BST ()            // Execute the Battery Status technique
    Notify (BAT0, 0x80)      // Tell OS the battery standing has modified
    ^BAT0._BIF ()            // Execute the Battery Information technique  
    Notify (BAT0, 0x81)      // Tell OS the battery information has modified
}

Which we will see right here:

Each of those operations requires communication with the Embedded Controller, including to the workload contained in the already-stalled interrupt handler.

The NOD2() technique sends notifications to the GPU driver.

Method (NOD2, 1, Serialized)
{
    If ((Arg0 != DNOT))
    {
        DNOT = Arg0
        Notify (^^PEG1.PEGP, Arg0)
    }

    If ((ROCT == 0x55))
    {
        ROCT = Zero
        Notify (^^PEG1.PEGP, 0xD1) // Hardware-Specific
    }
}

These notifications (0xD1, 0xD2, and so on.) are hardware-specific alerts that inform the NVIDIA driver to re-evaluate its energy state, which prompts driver power-state re-evaluation; in traces this surfaces as iGPU GFX0._PSx/_DOS toggles plus dGPU state modifications through PEPD._DSM/DGCE.

Here’s the place a easy however catastrophic oversight within the firmware’s logic causes system-wide failure. High-end ASUS gaming laptops characteristic a MUX (Multiplexer) change, a bit of {hardware} that lets the person select between two distinct graphics modes:

1. Optimus Mode: The power-saving default. The built-in Intel GPU (iGPU) is bodily linked to the show. The highly effective NVIDIA GPU (dGPU) solely renders demanding functions when wanted, passing completed frames to the iGPU to be drawn on display.
2. Ultimate/Mux Mode: The high-performance mode. The MUX change bodily rewires the show connections, bypassing the iGPU solely and wiring the NVIDIA dGPU on to the display. In this mode, the dGPU shouldn’t be non-obligatory; it’s the solely graphics processor able to outputting a picture.

Any firmware managing this {hardware} should pay attention to which mode the system is in. Sending a command supposed for one GPU to the opposite is futile and, in some circumstances, harmful. Deep throughout the ACPI code, a {hardware} standing flag named HGMD is used to trace this state. To perceive the flaw, we first must decipher what HGMD means, and the firmware itself offers us the important thing.

For display brightness to work, the command have to be despatched to the GPU that’s bodily controlling the show backlight. A command despatched to the flawed GPU will merely do nothing. Therefore, the brightness management technique (BRTN) should pay attention to the MUX change state to operate in any respect. It is the firmware’s personal Rosetta Stone.

// Brightness management - CORRECTLY checks for mux mode
Method (BRTN, 1, Serialized)  // Line 034003
{
    If (((DIDX & 0x0F0F) == 0x0400))
    {
        If (HGMD == 0x03)  // 0x03 = Ultimate/Mux mode
        {
            // In mux mode, notify discrete GPU
            Notify (_SB.PC00.PEG1.PEGP.EDP1, Arg0)
        }
        Else
        {
            // In Optimus, notify built-in GPU
            Notify (_SB.PC00.GFX0.DD1F, Arg0)
        }
    }
}

The logic right here is flawless and revealing. The code makes use of the HGMD flag to make a binary choice. If HGMD is 0x03, it sends the command to the NVIDIA GPU. If not, it sends it to the Intel GPU. The firmware itself, by means of this right implementation, offers the simple definition: HGMD == 0x03 means the system is in Ultimate/Mux Mode.

This excellent, platform-aware logic is totally deserted within the essential code paths answerable for energy administration. The LGPA technique, which is known as by the stutter-inducing interrupt, dispatches power-related instructions to the GPU with out ever checking the MUX mode.

// GPU energy notification - NO MUX CHECK!
Case (0x18)
{
    // This SHOULD have: If (HGMD != 0x03)
    // But it does not, so it runs even in mux mode
    If (M6EF == One)
    {
        Local0 = 0xD2
    }
    Else
    {
        Local0 = 0xD1
    }
    NOD2 (Local0)  // Notifies GPU no matter mode
}

This shouldn’t be a single typo. A second, parallel energy administration system within the firmware reveals the very same flaw. The Platform Extension Plug-in Device (PEPD) is utilized by Windows to handle system-wide energy states, resembling turning off shows throughout fashionable standby.

Device (PEPD)  // Line 071206
{
    Name (_HID, "INT33A1")  // Intel Power Engine Plugin
    
    Method (_DSM, 4, Serialized)  // Device Specific Method
    {
        // ... a lot of setup code ...
        
        // Arg2 == 0x05: "All displays have been turned off"
        If ((Arg2 == 0x05))
        {
            // Prepare for aggressive energy saving
            If (CondRefOf (_SB.PC00.PEG1.DHDW))
            {
                ^^PC00.PEG1.DHDW ()         // GPU pre-shutdown work
                ^^PC00.PEG1.DGCE = One      // Set "GPU Cut Enable" flag
            }
            
            If (S0ID == One)  // If system helps S0 idle
            {
                GUAM (One)    // Enter low energy mode
            }
            
            ^^PC00.DPOF = One  // Display energy off flag
            
            // Tell USB controller about show state
            If (CondRefOf (_SB.PC00.XHCI.PSLI))
            {
                ^^PC00.XHCI.PSLI (0x05)
            }
        }
        
        // Arg2 == 0x06: "A display has been turned on"
        If ((Arg2 == 0x06))
        {
            // Wake every part again up
            If (CondRefOf (_SB.PC00.PEG1.DGCE))
            {
                ^^PC00.PEG1.DGCE = Zero     // Clear "GPU Cut Enable"
            }
            
            If (S0ID == One)
            {
                GUAM (Zero)   // Exit low energy mode
            }
            
            ^^PC00.DPOF = Zero  // Display energy on flag
            
            If (CondRefOf (_SB.PC00.XHCI.PSLI))
            {
                ^^PC00.XHCI.PSLI (0x06)
            }
        }
    }
}

Once once more, the firmware prepares to chop energy to the discrete GPU with out first checking if it is the one GPU driving the shows. This demonstrates that the Mux Mode Confusion is a systemic design flaw. The firmware is internally inconsistent, main it to situation self-destructive instructions that attempt to cripple the system.

Traces from a number of ASUS gaming laptop computer fashions verify this isn’t an remoted situation.

• Trace Duration: 4.1 minutes
• _GPE._L02 Events: 7
• Avg. GPE Duration: 1.56ms (decrease, however nonetheless unacceptably excessive)
• Avg. Interval: 39.4 seconds (almost similar periodic nature)
• GPU Power Cycles: 8

• Trace Duration: 19.9 minutes
• _GPE._L02 Events: 3
• Avg. GPE Duration: 2.94ms
• GPU Power Cycles: 197 (much more frequent)
• ASUS WMI Calls: 2,370 (an enormous quantity, indicating software program amplification)

Microsoft has a built-in “smooth video” examine. It performs HD video in full display and watches for hiccups. If the PC drops frames, crackles, or any driver pauses for various milliseconds, it fails. That’s Microsoft’s baseline for what “smooth” ought to appear like.

Why it issues right here:

ASUS firmware is inflicting millisecond-long pauses. Those pauses are precisely the type that make this check fail i.e., the identical stutters and audio pops common customers discover on YouTube/Netflix and video games; this firmware violates fundemental requirements.

Despite being completely different fashions, all affected programs exhibit the identical core flaws:

1. _GPE._L02 handlers take milliseconds to execute as a substitute of microseconds.
2. The GPEs set off pointless battery polling.
3. The firmware makes an attempt to energy cycle the GPU whereas in a hard and fast MUX mode.
4. The whole course of is pushed by a periodic, timer-like set off.

This bug is a cascade of firmware design failures.

On home windows, the LXX / EXX run at PASSIVE_LEVEL through ACPI.sys however whereas a GPE management technique runs the firing GPE stays masked and ACPI/EC work is serialized. ASUS’s dispatch from GPE._L02 to ECLV loops, calls Sleep(25/100ms) and re-arms the EC stretching that masked window into tens of milliseconds (which might clarify the 13ms CPU time in ETW (Kernel ms) delay for GPE Events) and producing a periodic ACPI.sys burst that causes the latency issues on the system.The right conduct is to latch or clear the occasion, exit the strategy, and sign a driver with Notify for any heavy work; don’t self-rearm or sleep on this path in any respect.

The firmware artificially re-arms the interrupt, creating an infinite loop of GPEs as a substitute of clearing the supply and ready for the following reliable {hardware} occasion. This transforms a {hardware} notification system right into a disruptive, periodic timer.

The code that sends GPU energy notifications doesn’t examine if the system is in MUX mode, a essential state examine that’s appropriately carried out in different components of the firmware. This demonstrates inconsistency and a scarcity of high quality management.

This situation shouldn’t be new or remoted. User experiences documenting similar signs with excessive ACPI.sys DPC latency, periodic stuttering, and audio crackling have been accumulating since at the very least 2021 throughout ASUS’s whole gaming laptop computer lineup.

August 2021: The First Major Reports
The earliest documented circumstances seem on the official ASUS ROG boards. A G15 Advantage Edition (G513QY) proprietor experiences “severe DPC latency from ACPI.sys” with audio dropouts occurring underneath any load situation. The thread, final edited in March 2024, exhibits the problem stays unresolved after almost three years.

Reddit customers concurrently report identical ACPI.sys latency problems alongside NVIDIA driver points; the precise signs described on this investigation.

2021-2023: Spreading Across Models
Throughout this era, the problem proliferates throughout ASUS’s gaming lineup:

2023-2024: The Problem Persists in New Models
Even the most recent generations aren’t immune:

The proof is simple:

• Measured Proof: GPE handlers are measured blocking a CPU core for over 13 milliseconds.
• Code Proof: The decompiled firmware explicitly accommodates Sleep() calls inside an interrupt handler.
• Logical Proof: The code lacks essential checks for the laptop computer’s {hardware} state (MUX mode).
• Systemic Proof: The situation is reproducible throughout completely different fashions and BIOS variations.

Until a repair is applied, tens of millions of patrons of Asus laptops from approx. 2021 to current day are going through stutters on the only of duties, resembling watching YouTube, for the straightforward mistake of utilizing a sleep name inside an inefficient interrupt handler and never checking the GPU surroundings correctly.

The code is there. The traces show it. ASUS should repair its firmware.

ASUS has not responded to this investigation or the documented firmware points on the time of publication, will replace this if something modifications.

Investigation performed utilizing the Windows Performance Toolkit, ACPI desk extraction instruments, and Intel ACPI Component Architecture utilities. All code excerpts are from official ASUS firmware. Traces have been captured on a number of affected programs, all exhibiting constant conduct. I used an LLM for wording. The analysis, traces, and AML decomp are mine. Every declare is verified and reproducible when you observe the steps within the article; logs and instructions are within the repo. If you assume one thing’s flawed, cite the precise timestamp/technique/line. “AI wrote it” shouldn’t be an argument.