AsusゲーミングノートPCのACPIファームウェアバグ

• ASUS ROGゲーミングノートPCでは、ACPI.sysのDPC遅延により、音切れ、マウスのフリーズ、動画再生エラーなど深刻な性能低下が発生する
• 原因はファームウェア(BIOS)内の非効率または欠陥のあるACPI Machine Language(AML)コードにあり、OSやドライバーの入れ替えでは解決できない
• 周期的なハードウェアイベント(GPE) と組み込みコントローラー(EC)関連処理がCPU 0コアを占有し、Sleep()呼び出しなど不適切な割り込み処理によって待ち時間とシステム応答性に悪影響を与える
• ファームウェアはMUXモードを認識せずにGPUの電源サイクルを繰り返し、その結果、システムの一時停止からブルースクリーンまでさまざまな障害を引き起こす
• この問題は2021年以降、さまざまなASUS製ゲーミングノートPCモデルで一貫して報告されているが、ASUSの公式対応は進んでいない

---

プロジェクトの意義と背景

このオープンソースリポジトリは、ASUS製ゲーミングノートPC(ROGシリーズなど)で繰り返し発生するACPI.sysのDPC遅延問題の根本原因を、ファームウェアおよびACPIテーブルのレイヤーで分析した詳細な技術レポート。代表的にはZephyrus、Strix、Scarなどの高性能モデルで、YouTube視聴、音声/ビデオ通話、マウス操作など基本的な利用環境でも途切れ、ラグ、オーディオエラーが頻繁に発生する。ドライバー更新、Windows再インストール、Linuxへの移行など、さまざまな試みはいずれも効果がなく、原因はファームウェア内の誤ったAMLコードのみにある。

主な症状と測定結果

• LatencyMonなどのツールで測定すると、リアルタイムオーディオやその他の処理に不適と判定される
• ACPI.sysドライバーが割り込みとDPCルーチンで特定コア(CPU 0)を長時間占有していることが確認された
  • 割り込み-プロセス遅延: 最大65,816μs、平均23.29μs
  • DPCルーチン遅延: 最大5,998μs
• CPU 0が排他的に90秒以上割り込み処理に使われており、これはロードバランシングの失敗ではなく、ファームウェアが単一コアを占有するよう設計されていることを意味する
• 原因は単なるWindowsドライバーの問題ではなく、ファームウェア内の非効率または欠陥のあるAMLコードがACPI.sysに渡され実行されることに起因する。特にGPE(General Purpose Events)およびEmbedded Controller(EC) のトラフィックが問題を引き起こす

詳細分析: 高度なACPIログ追跡と問題パターン

• Windows Performance AnalyzerおよびETWトレースの結果、この遅延現象は30〜60秒周期で定期的に発生することが明らかになった
• 主要イベントである**_GPE._L02**ハンドラーが長時間実行され(例: 13.6ms)、その結果リアルタイム性能が深刻に低下する
• GPU電源管理コマンドがMUX(マルチGPU選択)モードの状態と無関係に繰り返し発生し、実際にはdGPUだけがディスプレイに接続されている環境で、不可能な状態遷移の試行が続く
• この過程でコンピューターがブルースクリーン(BSOD)で停止したり、ドライバースレッドが無限待機状態に陥るなど、致命的な障害が発生する

ファームウェアコードの抽出と逆コンパイル

• acpidump、iaslなどのツールでACPIテーブルを抽出し、逆コンパイルして分析
• 問題のGPEハンドラーは単純化すると
  • _L02: \_SB.PC00.LPCB.ECLV() 呼び出し
• しかしECLV()メソッド内部では
  • Sleep(25~100ms) などのCPU停止呼び出しを繰り返す
  • ECイベントキューが空でも人為的にイベントを生成(自己再武装)し、無限反復パターンを作る
• GPE内部でのスリープ呼び出しは割り込みコンテキストでは禁忌であり、1つのコアが数十msにわたりブロックされるため、リアルタイムスケジューリング/入力/オーディオなどに悪影響を及ぼす

イベント処理/ディスパッチおよび電源管理ロジック

• GPEイベントは、バッテリー状態およびGPU電源/ディスプレイ切り替え関連のラッパー関数呼び出しへとつながる
• PWCG(): バッテリー/ACアダプター状態のポーリングとOS通知シグナルを反復
• NOD2(): NVIDIAドライバーに電源状態の再評価を通知
• MUXモード状態(HGMD == 0x03)を確認して適切なGPUを対象に処理すべきだが、実際の該当箇所ではこれが省略されており、モードに関係なく無差別に電源サイクルコマンドを繰り返している

システム/モデル全体に共通する同一欠陥

• Scar 15、Zephyrus M16など複数モデルで、イベント実行時間、GPU電源サイクル周期、WMI呼び出しパターンがほぼ同一に観測される
• Armoury Crate(WMIサービス)がこの現象をさらに悪化させているとみられる

根本原因と設計失敗の要約

• 割り込みコンテキストの誤解: ファームウェアがGPEメソッド実行中にGPE信号をマスクするため、ACPI/EC処理が直列化され、内部のSleep()呼び出しで遅延が数十msに達する
• 割り込みの誤処理: GPEソースをクリアしないまま無限自己再武装を行い、繰り返しGPEを発生させる(周期タイマーのように動作)
• プラットフォーム(ハードウェア)状態の未認識: MUXモードかどうかを確認せずにGPU電源管理コマンドを送信
• 全体としてリアルタイム保証が求められる要件(オーディオ/ビデオなど)を満たせず、Microsoft公式HLK GlitchFreeテスト不合格の要因となる

ユーザー報告と問題の継続性

• 2021年からASUS公式フォーラムやRedditなどで同じ現象が繰り返し指摘されている
• Strix、TUF、Gシリーズを含む全ラインアップで症状に一貫性がある
• 2023〜2024年の最新モデルまで同じ欠陥が継続しており、一時的な回避策しか存在しない

結論: 問題の本質と示唆

• 測定上の証拠: GPEハンドラーが1つのコアを13ms以上ブロックする
• コード上の証拠: 割り込みハンドラー内にSleep()が明記されている
• 論理上の証拠: MUXモード確認の欠如
• システム上の証拠: 複数モデル/BIOSで再現を確認
• 「単に非効率な割り込みハンドラー内部のスリープとGPU状態未確認」というシンプルだが致命的な設計ミスにより、数百万台のASUSノートPCユーザーが基本作業ですら途切れを経験している
• ASUSは本分析時点まで公式な対応/修正計画を示していない

分析方法と参考

• 本レポートはWindows Performance Toolkit、acpidump、iaslなどのツールで実機からデータを抽出し、AMLコードを直接分析して導き出されたもの
• すべての主要証拠(トレース、メソッド、コマンド)は再現可能