Bug de firmware ACPI en laptops gamer de Asus
(github.com/Zephkek)- 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
1 comentarios
Opiniones en Hacker News
Me impresiona mucho este hallazgo, el artículo y la propuesta de corrección; muestra muy bien cómo funcionan las PCs modernas y hasta qué tan profundo se puede llegar en sus partes “ocultas”. Después de pasar años escribiendo firmware embebido, siempre soñé con que un usuario final encontrara un bug de este nivel. Me gustaría vivir en un mundo donde Asus invitara justo a usuarios talentosos así como contratistas de corto plazo para colaborar unos días con sus ingenieros de firmware, pagándoles decenas de miles de dólares y dándoles una laptop nueva con el BIOS de producción más reciente. Da tristeza que este bug haya sido ignorado por más de 4 años.
El análisis técnico de la causa es interesante, pero también me da curiosidad el análisis de la causa desde el lado de los procesos de negocio. Si este problema se reproduce de forma tan generalizada, me pregunto cómo no terminó reportándose por soporte técnico o por RMA. Me pregunto si no pudieron relacionarlo por falta de evidencia suficiente, o si ASUS sí investigó pero llegó a una conclusión equivocada, por ejemplo, un lote defectuoso de silicio, o incluso si había evidencia suficiente y simplemente la ignoraron. Si es un síntoma que aparece durante el uso normal, entonces ¿cómo era su proceso de QA? Parece un problema imposible de pasar por alto. Ahora que ya lo saben, me pregunto qué medidas podrían tomar. Si fuera una marca de lujo, tendría que resolver el problema y reparar su reputación de forma contundente para sobrevivir como marca. Compré un ROG en el pasado, pero después de ver algo así, no creo volver a comprar uno. Pensándolo otra vez, este bug de firmware en sí mismo es realmente impactante. Otros bugs pueden explicarse por cambios en supuestos de hardware o por errores al reutilizar código existente, pero poner un sleep dentro de una interrupción es grave. Me pregunto cómo eso pasó un code review y cómo habrán hecho las pruebas de firmware.
El bytecode AML de ACPI es un arma de doble filo. La ventaja es que permite hacer ingeniería inversa y que los usuarios analicen y corrijan bugs por su cuenta. Pero también es un entorno de programación espantoso, y además requiere ejecutar un intérprete bastante pesado con los máximos privilegios del kernel, lo cual es riesgoso. Los integradores de sistemas suelen usarlo para este tipo de trucos, y la calidad del código suele estar por debajo de lo esperable. Cuando uno termina haciendo drivers de Linux directamente, la experiencia siempre empieza por tirar a la basura el código ACPI.
Como usuario y programador, tener este tipo de conocimientos se siente como un sueño. El nivel de experiencia técnica contenido en el artículo me parece increíble. Yo también he analizado varias partes de laptops, pero me topé con una pared en la parte de ACPI; hice dumps de las tablas y hasta decompilé el código, pero todo eran puros códigos señuelo. Quise escribir yo mismo un driver de Linux para mi laptop, pero fracasé. Tengo muchísimo respeto por la gente capaz de lograr algo así.
Me pregunto cuál fue exactamente la corrección que salió. ¿La página de GitHub enlazada no terminaba básicamente en “ya publiqué todos los materiales, ahora que Asus lo arregle”?
Es un análisis realmente genial, y es impresionante lo mucho que Asus se esforzó en hacer QA de una calidad tan “basura”… bueno, en realidad da amargura pensar que no se esforzaron nada.
Sorprende que una laptop gamer haya tenido stuttering crítico durante 4 años. Me hace preguntarme por qué los consumidores no devolvieron el producto en masa. Citan un ejemplo de un post de Reddit enlazado: “ya intenté de todo y nada cambia, la mandé por garantía y me da curiosidad el resultado; el servicio dijo ‘no se encontró ninguna anomalía’, así que al final me acostumbré a usarla así y vivo con audífonos Bluetooth puestos sin notar el problema”.
Mis dos experiencias con laptops gamer terminaron igual, con problemas parecidos sin resolver. Una fue una Alienware M17 de primera generación, con dual GTX 270M y una Nvidia integrada. Tenía stuttering y ruido de audio, y lo resolví parcialmente desactivando SLI y la GPU integrada, usando un driver que encontré en algún foro. Más tarde salió un parche de BIOS que permitió volver a usar SLI, pero nunca hubo una solución completa y la máquina llegó al final de su vida útil. Mi segunda laptop ASUS ROG tuvo casi el mismo problema. Tampoco tenía el conocimiento para meterme al código ACPI y resolverlo del todo. LatencyMon atribuía el problema a varias dll, y probé mejoras temporales como cambiar el driver de Wi‑Fi o desactivar la dGPU. También había rarezas, como que el ruido aparecía menos en juegos. Al final dejé de comprar laptops gamer. Después de leer este artículo, me queda la impresión de que la situación todavía no ha mejorado mucho.
Es el resultado de una industria de computadoras que durante décadas le ha enseñado al consumidor que “estar roto es normal”. En cualquier otra industria, esto se devolvería todo el primer día. Hace 35 años un profesor mío lo comparó con unos zapatos que explotan al azar cuando te amarras las agujetas. Aun así, ahora al menos sí hay una tendencia a consolidar leyes de protección al consumidor.
La razón por la que terminé comprando un producto ASUS (Zenphyrus G14) fue que en cierto momento ASUS tenía casi exclusividad con los Ryzen 4xxxHS de AMD. Al principio rendía bien, pero dos años después ya se notaba la caída de rendimiento por thermal throttling. Volver a aplicar thermal pads solo ayudó parcialmente y nunca encontré la causa raíz. También revisé la degradación de batería, y resultó que el problema era que la iGPU siempre estaba funcionando a carga completa. De hecho, al configurar prioridad para la dGPU, la duración de batería mejoró un poco. Luego se fueron acumulando fallas mecánicas también, así que me cambié a una FW16 y ya no me quedaron ganas de volver a comprar una marca de laptops gamer. Me quedó la sensación de que al fabricante no le importan los consumidores, y se me fueron las ganas de comprarles.
Este defecto solo ocurre en modo Ultimate. Solo pasa cuando el usuario selecciona explícitamente la dGPU en el MUX. Esta función es importante para quienes juegan principalmente con monitor externo. En modo Optimus, las pantallas externas también funcionan bien, pero con una pequeña pérdida de rendimiento y con algunas funciones de pantalla limitadas, como G-Sync. Es muy probable que la mayoría de los usuarios usen solo el modo Optimus y por eso casi nunca se enteren de este defecto. El punto clave es que Asus envió hardware con funciones adicionales sin hacerles QA como corresponde. Parece que solo prueban bien el “golden path”.
Los usuarios de laptops Windows ya están tan acostumbrados a que nada funcione perfecto que simplemente desarrollaron el hábito de aguantar las molestias.
En la introducción decía que usaron un LLM (Large Language Model), y la verdad sí se nota demasiado ese estilo. La información es sólida, pero no me gusta porque ese tono excesivamente homogeneizado hace que no se sienta como un texto humano. Me pregunto por qué todo el mundo está tratando de evitar las expresiones humanas.
Me pregunto por qué los reviewers de productos, incluso sitios con buena reputación y enfoque proconsumidor como rtings o notebookcheck, no mencionan en sus reseñas desventajas que claramente todos conocen. Es amargo comprar un producto por el boca a boca y por reseñas espectaculares, tener problemas, y luego encontrarte en Reddit con respuestas del tipo “así son todas”. De verdad me pregunto por qué existe esa cultura.
Para encontrar realmente el problema, hay que poner la MUX switch en modo dGPU only y correr LatencyMon por más de 2 minutos. (No sé si también pasa en modo bypass de iGPU). notebookcheck sí registra los valores de LatencyMon y hasta indica que no es apta para audio en tiempo real.
reseña de ejemplo de notebookcheck Pero aun así no detectaron estas latencias extremas.
Viéndolo de una forma un poco más directa y sensible, parece razonable averiguar quién financia a esos sitios de reseñas.
Me pregunto si ese “programador” (aunque no sea la palabra exacta) siquiera probó el código que hacía sleep dentro de una interrupción, o si simplemente pasó por un departamento desconectado del resto al que no le importaba. También es muy posible que haya pasado pruebas automatizadas y simplemente hayan dicho “ya, suficiente”. Si hubiera existido un proceso tipo dogfooding al estilo Microsoft, es decir, que los desarrolladores usen realmente sus propios productos, probablemente alguien lo habría sufrido en su propia laptop y lo habría corregido.
El mismo problema ocurre en mi laptop gamer MSI de 2019 (GS65 Stealth). En menos de un minuto de correr LatencyMon ya aparecen stutters constantes de >10 ms. Si desactivo todos los dispositivos ACPI, el stuttering desaparece, pero al mismo tiempo deja de funcionar la dGPU. Sospecho que este problema podría estar ampliamente relacionado con muchas laptops gamer con dGPU. También comparto este post del foro de MSI sobre latencia de ACPI: post del foro de MSI sobre el fenómeno de latencia de ACPI. Recomiendo buscar "nvidia gaming laptop stutter latencymon acpi".
Resumen: no compren laptops gamer ASUS hasta que este defecto esté completamente resuelto; si todavía están dentro del período de garantía, recomiendo presentar un reclamo de garantía y estar listos incluso para llegar a Small Claims Court.
Entiendo a la gente que impulsa las Mac fabricadas en EE. UU. No puedo creer que un problema tan serio haya salido al mercado durante casi 4 años. Al menos ya tengo muy claro qué no voy a comprar en el futuro.
Apple también ha tenido problemas parecidos. Por ejemplo, hubo un caso relacionado con un issue de firmware EFI que fue negado.
artículo relacionado
Para los usuarios “fuera del campo de distorsión”, está claro que Apple también tiene sus propios problemas.
Usé Mac en el trabajo durante 8 años y, en general, funcionaban bien, pero tuve dos problemas grandes. a) Una vez dejó de cargar de repente, así que como todavía tenía batería llena, alcancé a mover los datos para recuperarlos; extrañé el almacenamiento removible. b) Durante un año, al iniciar streaming con iTunes, había como un 25% de probabilidad de que sonara un ruido horrible en vez de la música; si le dabas reproducir otra vez, casi siempre se arreglaba. Empezó en una versión específica del OS y se corrigió en la siguiente; no me pasaba con otras apps. Como existe la percepción de que “la Mac siempre es perfecta”, casi no había información y terminé perdiendo mucho tiempo. Menos grave, pero también tenía el problema de que si abría Outlook y cerraba la tapa de la laptop, se drenaba la batería y generaba calor. Outlook tiene mala fama, pero en una empresa con Exchange terminas pensando que simplemente conviene usarlo.
En laptops MSI también hubo un problema real donde un bug de EFI dejaba el sistema sin poder arrancar por UEFI al ejecutar
rm -rf /.explicación del issue
Sobre eso de “impulsar las Mac”, me pregunto si también lo dirían en el caso de gamers o usuarios de VR.
Desde alrededor de 2015 decidí no volver a comprar laptops con gráficos conmutables, y me ha funcionado bien. Siempre me parece ridículo ver cómo marcas “premium” invierten casi nada en personal de desarrollo de firmware mientras gastan cantidades enormes en marketing.
ASUS podría haber mejorado la experiencia de millones de usuarios, reducido costos de reemplazo y fortalecido su reputación de marca invirtiendo apenas el 0.01% de su presupuesto de marketing. Este tipo de cosas demuestra cómo muchas empresas están mal gestionadas porque creen erróneamente que el marketing es más eficaz que una buena ingeniería.