Bug du firmware ACPI sur les PC portables gaming Asus

• Sur les PC portables gaming ASUS ROG, un phénomène de latence DPC d’ACPI.sys provoque de graves baisses de performances, comme des coupures audio, des blocages de la souris et des erreurs de lecture vidéo
• La cause provient d’un code ACPI Machine Language (AML) inefficace ou défectueux dans le firmware (BIOS), et ne peut pas être corrigée en changeant de système d’exploitation ou de pilotes
• Des événements matériels périodiques (GPE) et des tâches liées au contrôleur embarqué (EC) monopolisent le cœur CPU 0, et une mauvaise gestion des interruptions, notamment des appels à Sleep(), dégrade fortement la latence et la réactivité du système
• Le firmware répète les cycles d’alimentation du GPU sans tenir compte du mode MUX, ce qui provoque divers dysfonctionnements, allant du gel du système jusqu’à l’écran bleu
• Ce problème est signalé de manière constante sur divers modèles de PC portables gaming ASUS depuis 2021, et aucune réponse officielle d’ASUS n’a été apportée

---

Importance et contexte du projet

Ce dépôt open source est un rapport technique approfondi qui analyse, au niveau du firmware et des tables ACPI, la cause profonde du problème récurrent de latence DPC d’ACPI.sys sur les PC portables gaming ASUS (série ROG, etc.). Des modèles hautes performances comme les Zephyrus, Strix ou Scar connaissent fréquemment des microcoupures, du lag et des erreurs audio dans des usages de base comme regarder YouTube, participer à des appels vocaux/vidéo ou simplement déplacer la souris. Toutes les tentatives classiques — pilotes, réinstallation de Windows, passage à Linux — se révèlent inefficaces, car la cause réside uniquement dans un code AML erroné dans le firmware.

Principaux symptômes et résultats de mesure

• Des outils comme LatencyMon indiquent que le système n’est pas capable de traiter l’audio temps réel et d’autres tâches sensibles
• Il a été confirmé que le pilote ACPI.sys occupe un cœur spécifique (CPU 0) pendant de longues périodes dans les routines d’interruption et de DPC
  • Latence interruption-vers-processus : maximum 65,816μs, moyenne 23.29μs
  • Latence des routines DPC : maximum 5,998μs
• CPU 0 est utilisé de manière exclusive pour le traitement des interruptions pendant plus de 90 secondes, ce qui signifie qu’il ne s’agit pas d’un échec du load balancing, mais que le firmware est conçu pour monopoliser un seul cœur
• La cause n’est pas un simple problème de pilote Windows, mais le fait que le firmware transmet à ACPI.sys un code AML inefficace ou défectueux, qui est ensuite exécuté. En particulier, le trafic lié aux GPE (General Purpose Events) et au contrôleur embarqué (EC) provoque le problème

Analyse détaillée : traçage ACPI avancé et motifs du problème

• Les résultats de Windows Performance Analyzer et du traçage ETW montrent que ces pics de latence surviennent régulièrement toutes les 30 à 60 secondes
• Le gestionnaire de l’événement principal _GPE._L02 s’exécute longuement (par exemple 13.6ms), ce qui dégrade sévèrement les performances temps réel
• Les commandes de gestion d’alimentation du GPU se répètent sans tenir compte de l’état du mode MUX (sélection multi-GPU), et des tentatives impossibles de changement d’état continuent même dans un environnement où seul le dGPU est relié à l’affichage
• Au cours de ce processus, des défaillances critiques surviennent, comme un arrêt sur écran bleu (BSOD) ou des threads de pilote bloqués dans un état d’attente infini

Extraction et décompilation du code du firmware

• Analyse réalisée après extraction et décompilation des tables ACPI avec des outils comme acpidump, iasl
• Le gestionnaire GPE en cause se résume à
  • _L02: _SB.PC00.LPCB.ECLV() appel
• Mais à l’intérieur de la méthode ECLV(), on trouve
  • des appels répétés bloquants pour le CPU, comme Sleep(25~100ms)
  • une génération artificielle d’événements même quand la file d’événements EC est vide (auto-réarmement), créant un motif de boucle infinie
• Les appels à Sleep dans un GPE sont interdits dans un contexte d’interruption et bloquent un cœur pendant plusieurs dizaines de ms, ce qui nuit à l’ordonnancement temps réel, aux entrées utilisateur et à l’audio

Logique de traitement/distribution des événements et gestion d’alimentation

• Les événements GPE entraînent l’appel de fonctions wrapper liées à l’état de la batterie ainsi qu’aux transitions d’alimentation/affichage du GPU
• PWCG() : interrogation de l’état de la batterie/de l’adaptateur secteur et répétition des signaux de notification vers l’OS
• NOD2() : notification au pilote NVIDIA pour réévaluer l’état d’alimentation
• Le système devrait vérifier l’état du mode MUX (HGMD == 0x03) afin de cibler le bon GPU, mais cette vérification est omise dans le chemin réel d’exécution, ce qui entraîne la répétition de commandes de cycle d’alimentation aveugles quel que soit le mode

Même défaut à l’échelle du système et des modèles

• Sur plusieurs modèles comme le Scar 15 et le Zephyrus M16, le temps d’exécution des événements, la périodicité des cycles d’alimentation du GPU et les motifs d’appel WMI sont presque identiques
• Il est supposé que Armoury Crate (service WMI) aggrave encore le phénomène

Résumé de la cause racine et de l’échec de conception

• Mauvaise compréhension du contexte d’interruption : le firmware masque le signal GPE pendant l’exécution de la méthode GPE, ce qui sérialise les tâches ACPI/EC, et les appels internes à Sleep() portent la latence à plusieurs dizaines de ms
• Gestion incorrecte des interruptions : répétition de GPE via auto-réarmement infini sans effacement de la source GPE (agissant comme un minuteur périodique)
• Méconnaissance de l’état de la plateforme (matériel) : envoi de commandes de gestion d’alimentation du GPU sans vérifier le mode MUX
• Dans l’ensemble, le système ne satisfait pas les exigences de garanties temps réel (audio/vidéo, etc.), ce qui en fait une cause d’échec au test officiel Microsoft HLK GlitchFree

Témoignages d’utilisateurs et persistance du problème

• Depuis 2021, le même phénomène est signalé à répétition sur les forums officiels ASUS, Reddit, etc.
• Les symptômes sont cohérents sur toute la gamme, y compris les séries Strix, TUF et G
• Le même défaut persiste jusqu’aux modèles récents 2023~2024, avec uniquement des solutions de contournement temporaires

Conclusion : nature du problème et implications

• Preuve par la mesure : le gestionnaire GPE bloque un cœur pendant plus de 13ms
• Preuve dans le code : présence explicite de Sleep() dans le gestionnaire d’interruption
• Preuve logique : absence de vérification du mode MUX
• Preuve système : reproduction confirmée sur plusieurs modèles/BIOS
• Une erreur de conception simple mais fatale — « simplement un Sleep inefficace dans un gestionnaire d’interruption et l’absence de vérification de l’état du GPU » — fait que des millions d’utilisateurs de PC portables ASUS subissent des saccades même dans les tâches les plus basiques
• ASUS n’a présenté, à la date de cette analyse, aucun plan officiel de réponse ou de correction

Méthode d’analyse et références

• Ce rapport a été établi à partir d’extractions de données sur machine réelle et d’une analyse directe du code AML à l’aide d’outils comme Windows Performance Toolkit, acpidump et iasl
• Toutes les principales preuves (traces, méthodes, commandes) sont reproductibles

[GN⁺]

Commentaires Hacker News

• Je suis impressionné par cette découverte, par l’article et par la proposition de correctif ; cela montre très bien comment fonctionnent les PC modernes et jusqu’où l’on peut creuser dans leurs parties « cachées » Après avoir écrit du firmware embarqué pendant des années, j’ai toujours rêvé qu’un utilisateur final découvre un bug de ce niveau J’aimerais vivre dans un monde où Asus inviterait justement ce genre d’utilisateur talentueux en contrat court pour collaborer quelques jours avec ses ingénieurs firmware, le rémunérer à hauteur de plusieurs dizaines de milliers de dollars, et lui remplacer son portable par un modèle neuf avec le dernier BIOS de production Il est triste que ce bug soit resté ignoré pendant plus de 4 ans

  • L’analyse de la cause technique est intéressante, mais je suis aussi curieux de l’analyse des causes du côté des processus métier Si ce problème est largement reproductible, je me demande comment il n’a pas été remonté via le support technique ou les RMA Je me demande s’il y avait trop peu d’éléments pour faire le lien, ou si ASUS a enquêté mais tiré une mauvaise conclusion (par exemple un lot de silicium défectueux), ou peut-être s’il y avait assez de preuves mais qu’elles ont été ignorées Si le symptôme se manifeste juste en usage normal, à quoi ressemblait donc le processus de QA ; n’est-ce pas un problème impossible à manquer ? Maintenant qu’ils le savent, je me demande quelles mesures ils sont susceptibles de prendre S’il s’agissait d’une marque de luxe, elle devrait régler le problème comme la restauration de sa réputation pour survivre J’ai déjà acheté du ROG, mais après avoir vu ce problème, je ne pense pas en racheter À y repenser, ce bug firmware en lui-même est vraiment choquant D’autres bugs peuvent s’expliquer par un changement d’hypothèses matérielles ou par une erreur liée à la réutilisation de code existant, mais faire dormir dans une interruption, c’est grave Je me demande comment cela a pu passer la revue de code, et comment les tests firmware ont été menés

  • Le bytecode AML d’ACPI est une arme à double tranchant Son avantage, c’est qu’il permet le reverse engineering et que les utilisateurs peuvent eux-mêmes analyser et corriger des bugs Mais c’est un environnement de programmation horrible, et il faut en plus exécuter un interpréteur assez lourd avec les privilèges les plus élevés du kernel, ce qui est risqué Les intégrateurs système s’en servent souvent pour ce genre de bricolage, mais la qualité du code est inférieure à tout ce qu’on pourrait espérer Quand on finit par écrire directement un driver Linux, on commence presque toujours par jeter le code ACPI

  • En tant qu’utilisateur et programmeur, posséder ce genre de savoir-faire relève du rêve Je trouve le niveau d’expertise contenu dans l’article impressionnant J’ai moi aussi analysé plusieurs parties de mon portable, mais je me suis heurté à un mur sur la partie ACPI, et même après avoir dumpé les tables et décompilé le code, ce n’était que du code leurre J’aurais voulu écrire moi-même le driver Linux de mon portable, mais j’ai échoué J’ai beaucoup de respect pour ceux qui arrivent à faire ce genre de travail

  • Je me demande quel correctif est effectivement sorti La page GitHub liée ne se termine-t-elle pas simplement sur « j’ai tout publié, à Asus de corriger » ?

  • Analyse vraiment brillante, et quel exploit de voir Asus consacrer tant d’efforts à QA une qualité aussi « pourrie »… enfin, façon de parler, puisqu’en réalité ils n’ont visiblement fait aucun effort, ce qui laisse un goût amer

• Il est surprenant qu’un portable gaming ait souffert d’un stuttering critique pendant 4 ans Cela amène à se demander pourquoi les consommateurs n’ont pas massivement retourné le produit On cite l’exemple d’un post Reddit lié : « j’ai tout essayé mais rien n’a changé, je l’ai envoyé sous garantie et j’attends de voir, le service a conclu à “aucune anomalie”, donc au final je me suis simplement habitué à l’utiliser comme ça, avec des écouteurs Bluetooth, sans trop remarquer le problème »

  • Mes deux expériences avec des portables gaming ont connu des problèmes similaires jamais vraiment résolus Le premier était un Alienware M17 de première génération, équipé de deux GTX 270M et d’un GPU Nvidia intégré Il y avait du stuttering et du bruit audio, et j’avais partiellement atténué le problème en désactivant le SLI et le GPU intégré, puis en utilisant un driver trouvé sur un forum Plus tard, un patch BIOS a permis de réutiliser le SLI, mais il n’y a jamais eu de solution complète, et la machine a fini sa vie ainsi Le second, un portable ASUS ROG, présentait presque exactement les mêmes symptômes Je n’avais pas non plus les connaissances nécessaires pour creuser le code ACPI, donc je n’ai pas pu le résoudre complètement LatencyMon attribuait le problème à plusieurs DLL, et j’ai tenté des améliorations temporaires en changeant le driver Wi‑Fi, en désactivant le dGPU, etc. Il y avait aussi des comportements étranges, comme le fait que le bruit se produisait moins souvent dans les jeux J’ai fini par arrêter d’acheter des portables gaming En lisant cet article, j’ai l’impression que la situation ne s’est pas vraiment améliorée aujourd’hui

  • C’est le résultat de décennies pendant lesquelles l’industrie informatique a appris aux consommateurs que « cassé, c’est normal » Dans n’importe quelle autre industrie, tout aurait été retourné dès le premier jour Il y a 35 ans, mon professeur comparait cela à des chaussures qui exploseraient aléatoirement quand on fait ses lacets Cela dit, nous évoluons maintenant vers un monde où les lois de protection des consommateurs s’installent

  • Si j’ai acheté un produit ASUS (Zenphyrus G14), c’est parce qu’à une époque ASUS avait quasiment l’exclusivité des Ryzen 4xxxHS d’AMD Au début les performances étaient bonnes, mais au bout de deux ans, une dégradation due au thermal throttling est apparue Remettre de la pâte ou des pads thermiques n’a aidé que partiellement, sans que je trouve la cause racine J’ai aussi cherché du côté de la dégradation de la batterie, avant de découvrir que le problème venait du fait que l’iGPU tournait en permanence à pleine charge En donnant la priorité au dGPU, l’autonomie s’est même légèrement améliorée Avec en plus des défauts mécaniques qui s’accumulaient, je suis passé à un FW16 et je n’ai plus envie de racheter un produit d’une marque de portables gaming J’ai l’impression que le constructeur ne se soucie pas des consommateurs, et cela m’a ôté toute envie d’achat

  • Ce défaut ne se produit qu’en mode Ultimate Il n’apparaît que lorsque l’utilisateur force explicitement le basculement MUX vers le dGPU Cette fonction est un atout important pour ceux qui jouent surtout sur un écran externe En mode Optimus, l’écran externe fonctionne aussi correctement, avec seulement une légère perte de performance et quelques limitations sur certaines fonctions d’affichage (G-Sync, etc.) La plupart des utilisateurs n’utilisent probablement que le mode Optimus et ont donc peu de chances de découvrir ce défaut Le fond du problème, c’est qu’Asus a expédié un produit avec des fonctions matérielles supplémentaires sans les tester correctement en QA Ils ont l’air de ne bien tester que le « golden path »

  • Les utilisateurs de portables Windows sont déjà tellement désensibilisés à l’idée que tout ne fonctionne pas parfaitement qu’ils ont pris l’habitude de simplement supporter l’inconfort

• L’introduction dit qu’un LLM (Large Language Model) a été utilisé, et ça se sent vraiment beaucoup dans le style Les informations sont solides, mais ce ton excessivement lissé me déplaît, car il ne donne pas l’impression d’un texte humain Je me demande pourquoi tout le monde semble vouloir éviter les formulations humaines

• Je me demande pourquoi les testeurs de produits, y compris des sites réputés et plutôt favorables aux consommateurs comme rtings ou notebookcheck, n’évoquent pas dans leurs tests des défauts pourtant connus de tous On achète un produit séduit par le bouche-à-oreille et des critiques dithyrambiques, puis quand on rencontre le problème et qu’on va sur Reddit, on ne voit que des réactions du type « c’est normal, ils font tous ça », et c’est assez amer Je me demande vraiment d’où vient cette culture

  • Pour trouver réellement le problème, il faut mettre le MUX en mode dGPU only et lancer LatencyMon pendant plus de 2 minutes (je ne sais pas si c’est aussi le cas en mode iGPU bypass) notebookcheck a effectivement relevé des mesures LatencyMon et a même explicitement écrit que la machine n’était pas adaptée à l’audio temps réel
    Exemple de test notebookcheck En revanche, ils n’ont pas constaté ce niveau extrême de latence

  • Si l’on veut être un peu plus direct et sensible à cette question, il est raisonnable de regarder qui sponsorise ces sites de tests

• Je me demande si ce « programmeur » (ce n’est pas le terme exact, mais disons) a vraiment testé du code qui fait dormir dans une interruption, ou si cela a simplement été laissé passer avec indifférence par un autre département dans une organisation trop fragmentée Il est aussi très possible qu’ils aient juste vu passer les tests automatisés et se soient dit « plus besoin d’y penser » S’il y avait eu un vrai processus de dogfooding à la Microsoft, c’est-à-dire où les développeurs utilisent réellement leur propre produit, ils auraient probablement rencontré ce problème sur leur propre portable et l’auraient corrigé

  • Quand je faisais autrefois du consulting firmware dans une grande entreprise hardware de Taipei, j’ai pris l’habitude de simplement ignorer les bugs Quand on remontait un bug, on se faisait reprocher de faire autre chose que le travail prévu L’équipe hardware appelait les développeurs firmware/driver/software par des termes inférieurs, et il y avait une ambiance où l’on ignorait les retours Donc ce genre d’histoire ne m’étonne pas

• Le même problème se produit sur mon portable gaming MSI de 2019 (GS65 Stealth) En moins d’une minute de LatencyMon, des stutters de >10 ms apparaissent en continu Si je désactive tous les périphériques ACPI, les stutters disparaissent, mais le dGPU devient en même temps inutilisable Je soupçonne que ce problème soit largement lié à de nombreux portables gaming équipés de dGPU Je mentionne aussi ce post du forum MSI sur la latence ACPI Je recommande de chercher « nvidia gaming laptop stutter latencymon acpi »

• En résumé : n’achetez pas de portable gaming ASUS tant que ce défaut n’est pas complètement corrigé ; et s’il est encore sous garantie, je recommande de faire une réclamation au titre de la garantie, voire de se préparer à aller jusqu’à la Small Claims Court

  • La plupart des portables n’ont de toute façon pas ce mode dGPU only dans lequel ce bug se manifeste En pratique, sur mon portable, je n’ai jamais utilisé le mode dGPU only via le MUX ; ce mode consomme simplement plus d’énergie pour un bénéfice presque nul

• Je comprends ceux qui poussent les Mac américains Il est difficile de croire qu’un problème aussi grave ait pu être expédié pendant près de 4 ans Je sais désormais clairement quoi ne plus acheter à l’avenir

  • Apple a aussi eu des problèmes similaires Par exemple, il y a eu un cas de refus autour d’un problème de firmware EFI
    Article lié

  • Même pour les utilisateurs « hors champ de distorsion », Apple a clairement ses propres problèmes

  • J’ai utilisé des Mac au travail pendant 8 ans, et dans l’ensemble cela fonctionnait bien, mais j’ai eu deux gros ennuis a) un jour la charge s’est brutalement arrêtée ; comme la batterie était encore pleine, j’ai immédiatement déplacé les données pour me protéger, et j’ai regretté l’absence de stockage amovible b) pendant un an, avec iTunes, il y avait environ 25 % de chances qu’au lancement d’un stream, au lieu de la musique, un bruit très violent sorte ; relancer la lecture résolvait le problème la plupart du temps Cela avait commencé sur une version précise de l’OS et a été corrigé sur la suivante ; cela ne se produisait pas avec d’autres applications Comme il y avait cette idée que « les Mac sont forcément parfaits », je n’ai trouvé aucune information et j’ai perdu du temps à chercher moi-même Moins grave, mais il y avait aussi un problème de consommation batterie et de chauffe lorsqu’on fermait le capot du portable avec Outlook ouvert Outlook a mauvaise réputation, mais dans une entreprise sous Exchange, on finit par penser que c’est quand même la meilleure option

  • Sur des portables MSI aussi, un bug EFI a réellement provoqué un problème où la commande rm -rf / rendait l’amorçage UEFI impossible
    Explication du problème

  • À propos de l’expression « pousser les Mac », je me demande si cela vaut aussi pour les joueurs ou les utilisateurs de VR

• Vers 2015, j’ai décidé de ne plus jamais acheter de portable à graphismes commutables, et cette décision s’est révélée payante Je trouve toujours ridicule de voir des marques « premium » investir des clopinettes dans les équipes de développement firmware tout en dépensant des fortunes en marketing

  • Moi aussi, après avoir utilisé en 2013 un portable « Optimus », j’ai juré de ne plus jamais recommencer Cela m’a donné plus de contraintes et m’a davantage poussé vers des desktops ou des serveurs, mais je n’ai jamais regretté d’être revenu à un usage iGPU uniquement

• ASUS aurait pu améliorer l’expérience de millions d’utilisateurs, réduire les coûts de remplacement et renforcer sa réputation de marque en investissant seulement 0,01 % de son budget marketing Ce genre de situation montre que beaucoup d’entreprises sont mal dirigées, parce qu’elles croient à tort que le marketing est plus efficace qu’une bonne ingénierie