AsusゲーミングノートPCのACPIファームウェアバグ
(github.com/Zephkek)- 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コードを直接分析して導き出されたもの
- すべての主要証拠(トレース、メソッド、コマンド)は再現可能
1件のコメント
Hacker Newsの意見
本当に驚くべき発見と記事、そして修正提案だと感心した。現代のPCがどう動いているのか、そしてその「隠れた」部分までどこまで掘り下げられるのかをよく示していて感動した。 長年組み込みファームウェアを書いてきた立場として、エンドユーザーがこのレベルのバグを見つけてくれることを夢見ていた。 Asusがまさにこういう才能のあるユーザーを短期契約で招いて、ファームウェアエンジニアと数日協力してもらい、数万ドル規模の報酬を払い、最新のProduction BIOS入りノートPCを新しく渡す、そんな世界に住みたい。 このバグが4年以上放置されていた現実が悲しい。
技術的な原因分析も興味深いが、ビジネスプロセス面での原因分析も気になる。 こうした問題が広く再現しているなら、なぜ技術サポートやRMA経由で報告されなかったのか不思議だ。 証拠があまりに乏しくて関連付けられなかったのか、それともASUSが調査したにもかかわらず誤った結論（例: 不良シリコンのロット）に至ったのか、あるいは十分な証拠があったのに無視したのかと疑ってしまう。 使用中すぐ表面化する症状なら、QAプロセスはどうなっていたのか、見逃せない問題ではないのかと思う。 今わかった以上、どんな対応を取る可能性があるのか気になる。 もし高級ブランドなら、問題解決と評判回復の両方を確実にやらないとブランドは生き残れない。 過去にROGを買ったことはあるが、こういう問題を見た後ではもう買わない気がする。 改めて考えると、このファームウェアバグ自体が本当に衝撃的だ。 他のバグならハードウェア前提が変わったとか、既存コードの再利用で生じたミスと見なせるが、割り込みの中でスリープを入れるやり方は深刻すぎる。 それがどうやってコードレビューを通り、ファームウェアテストをどうしていたのか気になる。
ACPIのAMLバイトコードは諸刃の剣のようなものだ。 リバースエンジニアリングや、ユーザー自身がバグを分析して修正できる点は利点だ。 しかし恐ろしいプログラミング環境であるうえ、かなり重いインタプリタをカーネルの最高権限で動かさなければならず危険だ。 システム統合ベンダーはこうした小細工に使いがちだが、コード品質は期待以下だ。 Linuxドライバを自分で作ることになると、いつもACPIコードを捨てるところから始まる体験になる。
ユーザーでありプログラマーでもある立場として、こういうノウハウを持てるのは夢のようだ。 記事に込められた専門知識はすごいと感じる。 自分もノートPCのいろいろな部分を解析してみたが、ACPIのところで壁にぶつかり、テーブルをダンプしてコードも逆コンパイルしてみたものの、全部ダミーコードばかりだった。 自分のノートPC用Linuxドライバを自作したかったが失敗した。 こういうことを成し遂げる人たちに大きな敬意を送る。
どんな修正が出たのか気になる。 リンク先のGithubページは「資料は全部公開したので、あとはAsusが直してくれ」で終わっているだけではないかと質問している。
本当に見事な分析だし、Asusがこんな「ゴミ」品質をQAするのに手間をかけた点は大したものだ……というふりをしたくなるが、実際にはまったく努力していないので苦々しい。
ゲーミングノートPCで4年間も致命的なスタッターが出ていたという事実に驚く。 消費者が製品を大量返品しなかった心理が気になる。 リンク先のReddit投稿から、「できることは全部やったが何も変わらない、保証修理にも出してみたが結果が気になる、サービス結果は『異常なし』判定で、結局そのまま慣れてしまい、Bluetoothイヤホンを付けて問題に気付かず使っている」という例を引用している。
2回のゲーミングノートPC経験はどちらも似たような問題が解決しなかった。 1台目は初代Alienware M17で、デュアルGTX 270MとオンボードNvidia GPUを搭載していた。 スタッターとオーディオノイズが発生し、SLIとオンボードGPUを無効化し、どこかのフォーラムで見つけたドライバを使って部分的に解決した。 後になってBIOSパッチでSLIが使えるようにはなったが、結局完全な解決はなく、製品寿命を迎えた。 2台目のASUS ROGノートPCもほぼ同じ症状だった。 自分もACPIコードを掘り下げる知識がなく、完全には解決できなかった。 LatencyMonでは複数のdllに問題が割り当てられていて、Wi-Fiドライバの交換、dGPUの無効化などで一時的改善を試みた。 ゲーム中のほうがかえってノイズが少ないなど妙な点もあった。 結局ゲーミングノートPCを買うのをやめた。 この記事を見ると、今でも状況はあまり良くなっていない印象だ。
コンピュータ業界が何十年もかけて、消費者に「壊れた状態が正常だ」と教育してきた結果だ。 他の業界なら初日に全部返品される案件だろう。 35年前、私の先生は、靴ひもを結ぶたびランダムに爆発する靴みたいなものだと言っていた。 それでも今は、消費者保護法が定着していく流れではある。
自分がASUS製品（Zenphyrus G14）を買ったのは、かつてASUSがAMDのRyzen 4xxxHSを独占的に採用していたおかげだ。 最初は性能が良かったが、2年たつと熱スロットリングによる性能低下が表面化した。 サーマルパッドの塗り直しは部分的な助けにしかならず、根本原因は見つからなかった。 バッテリー性能低下も調べたが、実はiGPUが常にフルロードで動いていたのが原因だった。 dGPU優先に設定すると、むしろバッテリー駆動時間がわずかに改善した。 機械的な欠陥まで積み重なり、FW16に乗り換え、もうゲーミングノートPCブランド製品を買う気がなくなった。 メーカーが消費者をまったく気にしていないように感じ、購買意欲が消えた。
この不具合はUltimateモードでのみ発生する。 ユーザーがMUXでdGPUへ切り替えるよう明示的に指定した場合にだけ起こる。 この機能は、外部ディスプレイで主にゲームをするときに重要な追加機能だ。 Optimusモードでも外部ディスプレイは正常に動くが、わずかな性能低下と一部ディスプレイ機能（G-Syncなど）の制限があるだけだ。 ほとんどのユーザーはOptimusモードでしか使わないので、この不具合に気付く機会がほとんどない可能性が高い。 問題の核心は、Asusが追加ハードウェア機能を十分にQAテストしないまま出荷した点にある。 「ゴールデンパス」だけは確実にテストする傾向だと思う。
WindowsノートPCユーザーは、完璧には動かないという現実にすでに慣れきっていて、不便をただ耐える習性がついている。
冒頭でLLM（Large Language Model）を使ったと書いてあったが、確かにそういう文体が強く出ている。 情報はしっかりしているが、こういう過度に均されたトーンのせいで人間の仕事に見えず、気に入らない。 なぜ皆が人間らしい表現を避けようとするのか不思議だ。
製品レビューアー、さらには消費者寄りで評判の高いrtingsやnotebookcheckのようなところでさえ、みんなが知っている欠点ですらなぜレビューで言及しないのか不思議に思う。 口コミやstellarレビューに釣られて製品を買い、問題に遭遇して、Redditで「どれもこんなものだ」という反応しか見ないとやるせない。 なぜこんな文化があるのか本当に気になる。
実際に問題を見つけるには、MUXスイッチでdGPU onlyモードにしてLatencyMonを2分以上回す必要がある。 （iGPUパススルーモードでもそうなのかはわからない） notebookcheckはlatencymonの数値を実際に記録しており、リアルタイムオーディオには不適とまで明記している
notebookcheckのレビュー例 ただし、こうした極端なレイテンシは実際には発見していない。
もう少し直接的かつ敏感に見るなら、そういうレビューサイトが誰の支援を受けているのか調べるのが妥当だ。
その「プログラマー」（正確な表現ではないが）が、割り込みの中でスリープするコードを自分で実際にテストしたのか、それとも分業化された別部署で無関心に流されたのか気になる。 自動テストだけ通ったので「もう知らない」となった可能性も高い。 マイクロソフト流のdogfooding、つまり開発者が自社製品を実際に使うプロセスがあったなら、自分のノートPCでこういう現象を経験して直した可能性が高いと思う。
同じ問題が自分の2019年製MSIゲーミングノートPC（GS65 Stealth）でも起きる。 LatencyMonを回して1分以内に >10ms のスタッターが出続ける。 すべてのACPIデバイスを無効化するとスタッターは消えるが、同時にdGPUも使えなくなる。 この問題はdGPU搭載の多数のゲーミングノートPCに広く関係している可能性があると疑っている。 MSIフォーラムのACPI遅延投稿も紹介している。 "nvidia gaming laptop stutter latencymon acpi" で検索してみることを勧める。
要約: ASUSのゲーミングノートPCは、欠陥が完全に解決されるまで買わないほうがいい。保証期間内なら保証請求やSmall Claims Courtまで覚悟する準備を勧める。
米国製Macを推す人たちの気持ちがわかる。 こんな深刻な問題が4年近く出荷されていたなんて信じられない。 今後何を買わないかははっきり決まった。
Appleにも似たような問題はあった。 例として、EFIファームウェア問題の否認案件があった。
関連記事
「歪曲場の外」のユーザーから見ても、Apple独自の問題は確かに存在する。
会社でMacを8年使ってきて、概ねよく動いたが大きなトラブルを2つ経験した。 a) あるとき突然充電できなくなり、満充電のうちにすぐデータ移行して復旧した。取り外し可能なストレージが恋しかった。 b) 1年間、iTunesでストリーミング再生を始めると約25%の確率で音楽の代わりにひどいノイズが出た。再生し直すとたいてい解決した。 特定のOSバージョンで始まり、次のバージョンで解消され、他のアプリでは起きなかった。 「Macは本来完璧だ」という認識のせいで情報もなく、無駄に苦労した。 そこまで深刻ではないが、Outlookを開いたままノートPCのふたを閉じるとバッテリー消費と発熱が起きる問題もあった。 Outlookの評判は悪いが、Exchangeを使う会社では結局それを使うのがましだと思うようになった。
MSIノートPCでもEFIバグにより、
rm -rf /コマンド実行時にUEFIで起動不能になる問題が実際にあった。問題の説明
「Macを推す」という表現について、ゲーマーやVRユーザーにもそう言えるのかと質問している。
2015年ごろから、スイッチャブルグラフィックス搭載ノートPCは二度と買わないと決めていて、それはうまくいっている。 「プレミアム」ブランドがファームウェア開発人員には雀の涙ほどしか投資せず、マーケティングには莫大な金を使うのを見ると、いつも滑稽に感じる。
ASUSはマーケティング予算の0.01%を投じるだけでも、何百万ものユーザー体験を改善し、交換コストを減らし、ブランドの評判も上げられただろう。 こうした現象は、多くの企業が良いエンジニアリングよりマーケティングのほうが効率的だと誤って信じ、組織運営を間違えている証拠だ。