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