Bug de firmware ACPI em notebooks gamer da Asus

• Em notebooks gamer ASUS ROG, ocorre latência DPC do ACPI.sys, causando problemas graves de desempenho como cortes no áudio, travamentos do mouse e erros na reprodução de vídeo
• A causa vem de código ACPI Machine Language (AML) ineficiente ou defeituoso no firmware (BIOS), e não pode ser resolvida trocando o sistema operacional ou os drivers
• Eventos periódicos de hardware (GPE) e tarefas relacionadas ao controlador embarcado (EC) monopolizam o núcleo CPU 0, e tratamento incorreto de interrupções, como chamadas a Sleep(), afeta negativamente a latência e a responsividade do sistema
• O firmware repete ciclos de energia da GPU sem reconhecer o modo MUX, o que provoca desde congelamentos do sistema até telas azuis
• O problema vem sendo relatado de forma consistente desde 2021 em vários modelos de notebooks gamer da ASUS, e não há resposta oficial da ASUS em andamento

---

Importância e contexto do projeto

Este repositório open source é um relatório técnico aprofundado que analisa, no nível do firmware e das tabelas ACPI, a causa raiz do problema recorrente de latência DPC do ACPI.sys em notebooks gamer ASUS (incluindo a linha ROG). Modelos de alto desempenho como Zephyrus, Strix e Scar frequentemente apresentam engasgos, lag e erros de áudio até em cenários básicos de uso, como assistir YouTube, fazer chamadas de voz/vídeo ou mover o mouse. O problema não é resolvido por tentativas como troca de drivers, reinstalação do Windows ou migração para Linux; a causa está exclusivamente em código AML incorreto dentro do firmware.

Principais sintomas e resultados das medições

• Medições com ferramentas como LatencyMon indicam incapacidade de lidar com áudio em tempo real e outras cargas semelhantes
• Foi confirmado que o driver ACPI.sys ocupa por longos períodos um núcleo específico (CPU 0) durante interrupções e rotinas DPC
  • Latência de interrupção para processo: máximo de 65.816μs, média de 23,29μs
  • Latência de rotina DPC: máximo de 5.998μs
• A CPU 0 é usada exclusivamente por mais de 90 segundos no tratamento de interrupções, o que indica não uma falha de balanceamento de carga, mas sim que o firmware foi projetado para ocupar um único núcleo
• A origem não é um simples problema de driver do Windows, mas sim o fato de que código AML ineficiente ou defeituoso no firmware é entregue ao ACPI.sys para execução. Em especial, o tráfego de GPE (General Purpose Events) e do Embedded Controller (EC) provoca o problema

Análise detalhada: rastreamento avançado de logs ACPI e padrões do problema

• Resultados do Windows Performance Analyzer e de rastreamentos ETW mostram que a latência ocorre regularmente em intervalos de 30 a 60 segundos
• O handler do principal evento, _GPE._L02, executa por muito tempo (por exemplo, 13,6ms), degradando severamente o desempenho em tempo real
• Comandos de gerenciamento de energia da GPU são repetidos independentemente do estado do modo MUX (seleção gráfica múltipla), e tentativas impossíveis de transição de estado continuam ocorrendo mesmo em ambientes onde apenas a dGPU está conectada ao display
• Nesse processo, ocorrem falhas críticas como encerramento do computador com tela azul (BSOD) ou threads de driver entrando em espera infinita

Extração e descompilação do código do firmware

• As tabelas ACPI foram extraídas e analisadas por descompilação com ferramentas como acpidump e iasl
• O handler GPE problemático é, de forma simplificada,
  • _L02: chama \_SB.PC00.LPCB.ECLV()
• Porém, dentro do método ECLV() há:
  • repetição de chamadas que param a CPU, como Sleep(25~100ms)
  • geração artificial de eventos mesmo quando a fila de eventos EC está vazia (auto-reativação), criando um padrão de repetição infinita
• Chamadas de sleep dentro de GPE são proibidas em contexto de interrupção e bloqueiam um núcleo por dezenas de ms, prejudicando escalonamento em tempo real, entrada de dados, áudio etc.

Lógica de processamento/disparo de eventos e gerenciamento de energia

• Eventos GPE levam a chamadas de funções wrapper relacionadas ao estado da bateria e à troca de energia/display da GPU
• PWCG(): polling repetido do estado da bateria/adaptador AC e envio de sinais de notificação ao SO
• NOD2(): notifica o driver NVIDIA para reavaliar o estado de energia
• O correto seria verificar o estado do modo MUX (HGMD == 0x03) para atuar sobre a GPU adequada, mas na prática isso é omitido em certos trechos, repetindo comandos indiscriminados de ciclo de energia independentemente do modo

O mesmo defeito em todo o sistema/modelos

• Em vários modelos, como Scar 15 e Zephyrus M16, o tempo de execução de eventos, o período dos ciclos de energia da GPU e o padrão de chamadas WMI foram observados como quase idênticos
• Suspeita-se que o Armoury Crate (serviço WMI) agrave ainda mais o fenômeno

Resumo da causa raiz e da falha de projeto

• Interpretação errada do contexto de interrupção: o firmware mascara o sinal GPE durante a execução do método GPE, serializando tarefas ACPI/EC, e chamadas internas a Sleep() fazem a latência chegar a dezenas de ms
• Tratamento incorreto de interrupção: GPEs são repetidos por auto-reativação infinita sem limpar a origem do GPE (na prática, funcionando como temporizador periódico)
• Desconhecimento do estado da plataforma (hardware): comandos de gerenciamento de energia da GPU são enviados sem verificar se o modo MUX está ativo
• Como um todo, o sistema não atende às exigências de garantias de tempo real (áudio/vídeo etc.) e falha inclusive no teste oficial HLK GlitchFree da Microsoft

Relatos de usuários e persistência do problema

• Desde 2021, o mesmo fenômeno é levantado repetidamente no fórum oficial da ASUS, no Reddit e em outros locais
• Os sintomas são consistentes em toda a linha, incluindo Strix, TUF e a série G
• O mesmo defeito persiste até nos modelos mais recentes de 2023~2024, com apenas soluções temporárias de contorno disponíveis

Conclusão: a natureza do problema e suas implicações

• Evidência de medição: o handler GPE bloqueia um núcleo por mais de 13ms
• Evidência no código: presença explícita de Sleep() dentro do handler de interrupção
• Evidência lógica: ausência de verificação do modo MUX
• Evidência sistêmica: reprodução confirmada em vários modelos/BIOS
• Um erro de projeto simples, porém fatal — “apenas sleep ineficiente dentro do handler de interrupção e ausência de verificação do estado da GPU” — faz com que milhões de usuários de notebooks ASUS sofram engasgos até em tarefas básicas
• Até o momento desta análise, a ASUS não apresentou resposta oficial nem plano de correção

Método de análise e referência

• Este relatório foi produzido a partir da extração de dados em equipamentos reais e da análise direta do código AML com ferramentas como Windows Performance Toolkit, acpidump e iasl
• Todas as principais evidências (traces, métodos e comandos) são reproduzíveis