Bug de firmware ACPI em notebooks gamer da Asus
(github.com/Zephkek)- 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()
- _L02: chama
- 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
- repetição de chamadas que param a CPU, como
- 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 SONOD2(): 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
1 comentários
Opiniões no Hacker News
Fiquei impressionado com a descoberta, com o artigo e com a proposta de correção; isso mostra muito bem como os PCs modernos funcionam e até onde dá para investigar as partes “escondidas” Depois de anos escrevendo firmware embarcado, eu sempre sonhei que um usuário final encontrasse um bug desse nível Eu queria viver num mundo em que a Asus convidasse exatamente esse tipo de usuário talentoso para um contrato curto, trabalhando por alguns dias com os engenheiros de firmware, pagando dezenas de milhares de dólares e ainda trocando o notebook por um novo com a BIOS de produção mais recente É triste que esse bug tenha ficado largado por mais de 4 anos
A análise da causa técnica é interessante, mas eu também queria entender a análise da causa do ponto de vista do processo de negócios Se esse problema é amplamente reproduzível, como ele não foi reportado via suporte técnico ou RMA? Fico me perguntando se faltavam evidências para correlacionar os sintomas, se a ASUS investigou e chegou à conclusão errada, como um lote defeituoso de silício, ou se havia evidências suficientes e mesmo assim ignoraram Se o sintoma aparece em uso normal, como era o processo de QA? Não parece o tipo de problema que daria para deixar passar Agora que isso veio à tona, fico curioso sobre que tipo de ação eles podem tomar Se fosse uma marca de luxo, ela teria de resolver o problema e restaurar a reputação para continuar viva Já comprei ROG no passado, mas depois de ver isso acho que não compraria de novo Pensando melhor, esse bug de firmware em si é realmente chocante Outros bugs podem ser explicados por mudanças em premissas de hardware ou por erros vindos de reaproveitamento de código, mas colocar sleep dentro de uma interrupção é grave Como isso passou por code review e como o firmware foi testado?
O bytecode AML do ACPI é uma faca de dois gumes A vantagem é que permite engenharia reversa e que o próprio usuário analise e corrija bugs Mas é um ambiente de programação horrível e ainda exige rodar um interpretador relativamente pesado com os maiores privilégios do kernel, o que é perigoso Integradores de sistema costumam usar esse tipo de gambiarra, e a qualidade do código fica abaixo do esperado Quando a gente acaba criando drivers Linux diretamente, a experiência quase sempre começa jogando o código ACPI fora
Como usuário e programador, ter esse tipo de know-how parece um sonho O conhecimento especializado presente no artigo é impressionante Eu também já analisei várias partes de notebooks, mas sempre bati numa parede na parte de ACPI; cheguei a fazer dump das tabelas e descompilar o código, mas era tudo código de mentira Eu queria criar meu próprio driver Linux para o notebook, mas falhei Tenho enorme respeito por quem consegue fazer esse tipo de coisa
Fiquei curioso sobre qual correção saiu A página do GitHub linkada não termina basicamente com “publiquei todo o material, agora a Asus que corrija”?
Análise realmente excelente, e é impressionante como a Asus se esforçou para fazer QA dessa qualidade “lixo”… quer dizer, finge que se esforçou, porque na verdade não se esforçou nada, o que é amargo
É espantoso que notebooks gamer tenham apresentado stutter fatal por 4 anos Isso faz pensar na psicologia de por que os consumidores não devolveram esses produtos em massa Cita um exemplo do post no Reddit: “já tentei de tudo e nada mudou, mandei para a garantia e estou curioso com o resultado, o laudo foi ‘nenhum problema encontrado’, então acabei me acostumando e uso fones Bluetooth para não perceber o problema”
Minhas duas experiências com notebooks gamer tiveram problemas parecidos e nunca foram resolvidos Um deles foi um Alienware M17 de primeira geração, com GTX 270M em dual e GPU Nvidia onboard Havia stutter e ruído de áudio, e eu resolvi parcialmente desativando o SLI e a GPU onboard e usando um driver encontrado em algum fórum Depois saiu um patch de BIOS que permitiu usar SLI, mas nunca houve uma solução completa e o produto chegou ao fim da vida útil assim O segundo foi um notebook ASUS ROG com praticamente o mesmo comportamento Eu também não tinha conhecimento para mergulhar no código ACPI, então não consegui resolver por completo O LatencyMon atribuía o problema a várias DLLs, e eu tentava melhorias temporárias trocando o driver de Wi‑Fi, desativando a dGPU e coisas assim Também havia bizarrices, como menos ruído justamente durante jogos No fim, parei de comprar notebooks gamer Depois de ler este artigo, a impressão é que a situação ainda não melhorou muito
Isso é resultado de a indústria de computadores ter ensinado os consumidores por décadas que “quebrado é normal” Em outros setores, isso seria devolvido no primeiro dia Há 35 anos, meu professor comparou isso a sapatos que explodem aleatoriamente quando você amarra o cadarço Ainda assim, hoje existe uma tendência de consolidação das leis de proteção ao consumidor
O motivo de eu ter comprado um produto ASUS, um Zenphyrus G14, foi que por um tempo a ASUS adotou com exclusividade os Ryzen 4xxxHS da AMD No começo o desempenho era bom, mas dois anos depois ficou claro que havia perda por thermal throttling Reaplicar thermal pads ajudou só parcialmente, sem revelar a causa raiz Também investiguei a perda de autonomia da bateria e descobri que o problema era a iGPU rodando sempre em carga máxima Ao priorizar a dGPU, a duração da bateria até melhorou um pouco Somando isso a falhas mecânicas, acabei migrando para o FW16 e perdi qualquer vontade de comprar de novo produto de marca de notebook gamer Fiquei com a sensação de que o fabricante não liga para o consumidor, e isso matou minha vontade de comprar
Esse defeito só acontece no modo Ultimate Ele só ocorre quando o usuário explicitamente muda o MUX para dGPU Esse recurso é um adicional importante quando se joga principalmente em monitor externo No modo Optimus, os monitores externos também funcionam bem, com apenas uma pequena perda de desempenho e algumas limitações em recursos de tela, como G-Sync É bem provável que a maioria dos usuários use apenas o modo Optimus e quase nunca tenha chance de descobrir esse defeito O ponto central é que a Asus despachou um recurso extra de hardware sem fazer QA adequado Parece a velha tendência de testar só o “golden path”
Usuários de notebooks Windows já ficaram tão anestesiados ao fato de que as coisas não funcionam perfeitamente que desenvolveram o hábito de simplesmente aguentar o incômodo
O texto introdutório dizia que usaram LLM (Large Language Model), e dá para sentir demais esse estilo A informação é sólida, mas esse tom excessivamente nivelado faz com que não pareça um trabalho humano, e eu não gosto disso Fico me perguntando por que todo mundo tenta evitar uma expressão mais humana
Fico me perguntando por que reviewers de produtos, até mesmo lugares renomados e favoráveis ao consumidor como rtings e notebookcheck, não mencionam nos reviews nem mesmo defeitos que todo mundo conhece Você compra o produto levado por boca a boca e reviews excelentes, tem o problema, e no Reddit só recebe “é assim mesmo” Eu realmente queria entender por que essa cultura existe
Para encontrar o problema de verdade, é preciso deixar no modo dGPU only via chave MUX e rodar o LatencyMon por mais de 2 minutos (Não sei se isso também acontece no modo bypass da iGPU) O notebookcheck de fato registra números do LatencyMon e até afirma que a máquina é inadequada para áudio em tempo real
review de exemplo do notebookcheck Mas eles não detectaram essa latência extrema específica
Olhando de forma mais direta e sensível, parece razoável verificar por quem esses sites de review são patrocinados
Fico pensando se esse “programador” (não é bem o termo certo) chegou a testar o código que coloca sleep dentro da interrupção, ou se isso foi empurrado sem interesse por outro departamento dentro de uma estrutura de trabalho fragmentada Também é bem possível que tenha passado nos testes automatizados e simplesmente decidiram “deixa para lá” Se houvesse um processo no estilo dogfooding da Microsoft, ou seja, os próprios desenvolvedores usando o produto de verdade, é bem provável que eles teriam vivido isso nos próprios notebooks e corrigido o problema
O mesmo problema acontece no meu notebook gamer MSI de 2019, um GS65 Stealth Em menos de 1 minuto rodando o LatencyMon, aparecem stutters contínuos de >10 ms Se eu desativo todos os dispositivos ACPI, o stutter desaparece, mas aí também não dá para usar a dGPU Suspeito que esse problema possa estar amplamente relacionado a muitos notebooks gamer com dGPU Também apresenta o post do fórum MSI sobre latência ACPI Recomenda pesquisar por “nvidia gaming laptop stutter latencymon acpi”
Resumo: não compre notebooks gamer da ASUS até que esse defeito esteja totalmente resolvido; se ainda estiver na garantia, recomenda abrir solicitação de garantia e estar preparado até para levar ao Small Claims Court
Entendo as pessoas que empurram Macs fabricados nos EUA É inacreditável que um problema tão sério tenha sido embarcado por quase 4 anos Pelo menos já ficou claro o que eu não vou comprar daqui para frente
A Apple também já teve problemas parecidos Como exemplo, houve um caso de negação envolvendo issue de firmware EFI
artigo relacionado
Mesmo para usuários “fora do campo de distorção”, a Apple claramente tem seus próprios problemas
Usei Macs no trabalho por 8 anos e, no geral, eles funcionaram bem, mas tive dois grandes problemas a) certa vez ele simplesmente parou de carregar, então tive de transferir os dados rapidamente enquanto ainda tinha bateria; senti falta de armazenamento removível b) por um ano, ao iniciar streaming pelo iTunes, havia cerca de 25% de chance de tocar um ruído horrível em vez de música; ao reproduzir de novo, quase sempre resolvia Isso começou em uma versão específica do sistema e foi corrigido na seguinte; em outros apps isso não acontecia Como existe essa percepção de que “Mac é sempre perfeito”, eu não encontrava informação e só perdia tempo tentando entender Menos grave, mas também tive o problema de fechar a tampa com o Outlook aberto e o notebook continuar consumindo bateria e esquentando O Outlook tem má fama, mas em empresas que usam Exchange você acaba pensando que é melhor simplesmente usar
Notebooks MSI também já tiveram um bug de EFI em que executar o comando
rm -rf /realmente podia deixar o sistema sem boot UEFIexplicação do problema
Sobre essa ideia de “empurrar Macs”, pergunta se isso também valeria para gamers ou usuários de VR
Desde mais ou menos 2015, decidi que nunca mais compraria notebook com gráficos comutáveis, e isso funcionou bem para mim Sempre acho engraçado ver marcas “premium” investindo migalhas em equipe de desenvolvimento de firmware enquanto gastam fortunas em marketing
A ASUS poderia ter melhorado a experiência de milhões de usuários, reduzido custos de troca e fortalecido a reputação da marca investindo só 0,01% do orçamento de marketing Esse tipo de situação mostra como muitas empresas são mal administradas por acreditarem, de forma equivocada, que marketing é mais eficiente do que boa engenharia