Bug de firmware ACPI en laptops gamer de Asus

• En las laptops gamer ASUS ROG se presenta un fenómeno de latencia DPC de ACPI.sys que provoca audio entrecortado, congelamientos del mouse, errores en la reproducción de video y otros problemas graves de degradación del rendimiento
• La causa se origina en código ACPI Machine Language (AML) ineficiente o defectuoso dentro del firmware (BIOS), por lo que no puede resolverse cambiando el sistema operativo ni los drivers
• Eventos periódicos de hardware (GPE) y tareas relacionadas con el controlador embebido (EC) monopolizan el núcleo CPU 0 y, debido a manejo incorrecto de interrupciones como llamadas a Sleep(), afectan negativamente la latencia y la capacidad de respuesta del sistema
• El firmware repite ciclos de energía de la GPU sin reconocer el modo MUX, lo que provoca fallas que van desde bloqueos temporales del sistema hasta pantallas azules
• Este problema se ha reportado de forma consistente en varios modelos de laptops gamer ASUS desde 2021, y no hay una respuesta oficial de ASUS en curso

---

Importancia y contexto del proyecto

Este repositorio de código abierto es un informe técnico profundo que analiza la causa raíz del problema recurrente de latencia DPC de ACPI.sys a nivel de firmware y de tablas ACPI en laptops gamer ASUS (como la serie ROG). En particular, modelos de alto rendimiento como Zephyrus, Strix y Scar experimentan con frecuencia cortes, lag y errores de audio incluso en usos básicos como ver YouTube, hacer llamadas de voz o video, o mover el mouse. El problema no se resuelve con drivers, reinstalando Windows ni cambiando a Linux; la causa está únicamente en código AML incorrecto dentro del firmware.

Principales síntomas y resultados de medición

• Al medir con herramientas como LatencyMon, se determina que el sistema no puede procesar adecuadamente audio en tiempo real y otras tareas
• Se confirmó que el driver ACPI.sys ocupa durante largos periodos un núcleo específico (CPU 0) en interrupciones y rutinas DPC
  • Latencia de interrupción a proceso: máximo 65,816μs, promedio 23.29μs
  • Latencia de rutina DPC: máximo 5,998μs
• El CPU 0 se usa de forma exclusiva para el manejo de interrupciones durante más de 90 segundos, lo que indica que no es un fallo de balanceo de carga, sino que el firmware está diseñado para ocupar un solo núcleo
• La causa no es un simple problema del driver de Windows, sino que ACPI.sys ejecuta código AML ineficiente o defectuoso entregado por el firmware. En particular, el tráfico de GPE (General Purpose Events) y del Embedded Controller (EC) desencadena el problema

Análisis detallado: rastreo avanzado de logs ACPI y patrones del problema

• Según los resultados de Windows Performance Analyzer y el trazado ETW, esta latencia aparece de forma periódica cada 30 a 60 segundos
• El manejador del evento principal _GPE._L02 se ejecuta durante mucho tiempo (por ejemplo, 13.6ms), degradando seriamente el rendimiento en tiempo real
• Los comandos de administración de energía de la GPU se repiten sin importar el estado del modo MUX (selección de múltiples gráficos), por lo que se siguen intentando transiciones imposibles incluso en entornos donde solo la dGPU está conectada a la pantalla
• En este proceso se provocan fallas críticas, como que la computadora termine con una pantalla azul (BSOD) o que hilos del driver queden en espera infinita

Extracción y decompilación del código de firmware

• Las tablas ACPI se extrajeron y analizaron tras decompilarlas con herramientas como acpidump e iasl
• El manejador GPE problemático es, de forma simple:
  • _L02: llama a _SB.PC00.LPCB.ECLV()
• Pero dentro del método ECLV() ocurre lo siguiente:
  • llamadas repetidas que detienen la CPU, como Sleep(25~100ms)
  • incluso cuando la cola de eventos del EC está vacía, se generan eventos artificialmente (autorearmado), creando un patrón de repetición infinita
• Las llamadas a sleep dentro de un GPE son una práctica prohibida en contexto de interrupción, y bloquean un núcleo durante decenas de ms, afectando negativamente la programación en tiempo real, la entrada y el audio

Lógica de procesamiento/despacho de eventos y administración de energía

• Los eventos GPE terminan llamando funciones envoltorio relacionadas con el estado de la batería y con cambios de energía/pantalla de la GPU
• PWCG(): sondeo del estado de la batería/adaptador de CA y repetición de señales de notificación al SO
• NOD2(): notifica al driver de NVIDIA que reevalúe el estado de energía
• Debería comprobarse el estado del modo MUX (HGMD == 0x03) para actuar sobre la GPU correcta, pero en el tramo real esto se omite y se repiten comandos indiscriminados de ciclo de energía sin importar el modo

La misma falla en todo el sistema y en varios modelos

• En varios modelos, como Scar 15 y Zephyrus M16, se observan tiempos de ejecución de eventos, periodos de ciclo de energía de la GPU y patrones de llamadas WMI casi idénticos
• Se presume que Armoury Crate (servicio WMI) agrava aún más este fenómeno

Resumen de la causa raíz y del fallo de diseño

• Malentendido del contexto de interrupción: el firmware enmascara la señal GPE durante la ejecución del método GPE, serializando tareas ACPI/EC, y las llamadas internas a Sleep() elevan la latencia a decenas de ms
• Manejo incorrecto de interrupciones: se provocan GPE repetidos mediante autorearmado infinito sin limpiar la fuente GPE (actuando como temporizador periódico)
• Desconocimiento del estado de la plataforma (hardware): se envían comandos de administración de energía de la GPU sin verificar si el modo MUX está activo
• En conjunto, no se cumplen los requisitos de garantía en tiempo real (audio/video, etc.), lo que lleva a reprobar la prueba oficial HLK GlitchFree de Microsoft

Reportes de usuarios y persistencia del problema

• Desde 2021 se viene planteando repetidamente el mismo fenómeno en los foros oficiales de ASUS, Reddit y otros sitios
• Los síntomas son consistentes en toda la línea, incluidas las series Strix, TUF y G
• La misma falla continúa incluso en los modelos más recientes de 2023~2024, y solo existen soluciones temporales parciales

Conclusión: la naturaleza del problema y sus implicaciones

• Evidencia de medición: el manejador GPE bloquea un núcleo durante más de 13ms
• Evidencia de código: hay un Sleep() explícito dentro del manejador de interrupciones
• Evidencia lógica: falta la comprobación del modo MUX
• Evidencia del sistema: se confirmó la reproducción del problema en varios modelos y BIOS
• Un error de diseño simple pero crítico —"sleep dentro de un manejador de interrupciones ineficiente y sin verificar el estado de la GPU"— hace que millones de usuarios de laptops ASUS sufran cortes incluso en tareas básicas
• ASUS no ha presentado una respuesta oficial ni un plan de corrección hasta el momento de este análisis

Método de análisis y referencia

• Este informe se elaboró extrayendo datos de equipos reales y analizando directamente código AML con herramientas como Windows Performance Toolkit, acpidump e iasl
• Todas las pruebas principales (trazas, métodos, comandos) pueden reproducirse