トラブルの概要
2026年9月18日、日常使いしてるMuse Glimmer 30Bの能力テストを行ってみたいなーと思い、以下の診断ツールを使用としているとき、障害が発生しました。
ちょうどエージェント動作の評価をしてる最中に応答が返らなくなり、調べてみるとGPU処理が停止し、Xeドライバによるリセットが繰り返し発生したみたいです。
対象GPUはPCIアドレス0000:03:00.0、PCI IDは0xe223です。はい。我が家のIntel ARC PRO B70でございます。6.17.0-42-generic環境でこの頃は動かしており、そこでは、次のログが大量に出力されました。
xe 0000:03:00.0: [drm] GT0: trying reset from guc_exec_queue_timedout_job [xe]同じログが数十万回単位で繰り返されたため、systemd-journaldがログを処理できなくなって居た旨のダンプログは出力されていたようで、ここから先は我が家のGPT-5.6-Lunaエージェントと共に調べ事をした結果になります。
調査してみると、はい、関連プロセスもイッテマシタ。
systemd-journald.service: start operation timed out
/dev/kmsg buffer overrun, some messages lost
INFO: task llama-server blocked for more than 245 seconds
INFO: task xpu-smi blocked for more than 245 secondsllama-serverとxpu-smiは、どちらもXeのVM終了処理とDMA fence待ちで停止していました。ならばということで、以下のことを実行してまわりました。
- Kernelを6.18.0/6.19.0へ入れ替え→どーにもこうにももう一台のGPUであるNVIDIA RTX 3060が認識しない
- Kernelを7.0.0-31-genericへ更新→ apt full-upgrade ってコマンド初めて打ちました。
- ドライバ周り（NVIDIA-DriverやCUDA、OneAPI、Level-Zero Driverなど）の当て直し
- llama.cpp再コンパイル（このときバージョン更新も合わせて実施）
これでしばらく起きねーだろー・・・と思ったらまたこれがでたんですよ畜生。
Fault response: Unsuccessful -EINVAL
Engine reset: engine_class=ccs
Timedout job
Fault response: Unsuccessful -ENOENT
Engine reset: engine_class=bcsこうした問題ケースは、どうやらCCS(Compute Command Streamer:内部計算エンジン)、BCS(Blitter Command Streamer:コピーエンジン)リセット問題と呼ばれてるみたいです。いやはや、一念発起して買ったGPUですけど、いきなり崖っぷちに立たされてる私って･････････････････一体何なの？と。
内部で何が起こっていたのか
今回のログは、GPU上の計算処理だけでなく、GPU仮想メモリの処理にも異常が発生していたことを示していたようで、ページフォルト発生時に学のトラブルが引き起こされたみたいです。ページフォルトは、GPUが現在有効ではない仮想アドレスへアクセスしたときに発生する通知イベントを示しています。
GPT-5.6-Luna・・・Lunaさんと呼ぼう。このLunaさんの指示に従って、早急にデバイスダンプログを採取し、その後syslogからgrepかけながら必要ログを取得していくわけですけど、その中で時系列と障害発生の流れをある程度追いかけることが出来たのでそのあたりから説明してみます。（って言いながらほとんどLunaさんの説明です。はい・・全体で多分 684,756トークン消費してこの問題にあたってくれてました）
今回の最初の記録は次のとおりです。
Fault response: Unsuccessful -EINVAL
ASID: 462
Faulted Address: 0x0000d556a8ac7000
FaultType: 0
AccessType: 0
FaultLevel: 0
EngineClass: 3 bcs
EngineInstance: 0FaultType: 0は、対象ページが存在しないことを示します。
AccessType: 0は、読み取りアクセスです。EngineClass: 3 bcsは、BCS0というコピーエンジンからページフォルトが発生したことを示します。Xeドライバは、ページフォルトを受けると、ASIDから対象VMを探し、Faulted Addressに対応するVMAを探します。そのどちらかを解決できない場合、Xeは-EINVALを返します。
このため、19時54分の-EINVALは、ユーザー空間へ渡された単純な引数エラーではありません。GPUが参照した仮想アドレスを、Xeが現在のVMまたはVMAへ対応付けできなかったという意味です。その後、20時15分にはCCSのコンテキストリセットが発生しました。
Engine reset: engine_class=ccs, logical_mask: 0x1, guc_id=2, state=0x3
Timedout job: seqno=198, lrc_seqno=198, guc_id=2, flags=0x20 in llama-server同じ経路は21時41分にも再発しています。
Engine reset: engine_class=ccs, logical_mask: 0x1, guc_id=2, state=0x3
Timedout job: seqno=3514, lrc_seqno=3514, guc_id=2, flags=0x20 in llama-serverこの2回では、Engine resetがTimedout jobより先に記録されています。
そのため、単純に「カーネルのタイムアウト検出が先に起きて、その後にリセットした」とは限りません。GuCまたはGPU側ですでにCCSコンテキストがリセットされ、その後にDRM schedulerが未完了ジョブをTimedout jobとして処理した可能性があるとのこと・・・すげぇな・・・
デバイスコアダンプでも、対象はCCS計算キューでした。
Context: ccs2
Class: COMPUTE
Reason: Timedout job
Schedule State: REGISTERED|RESET|BANNED
LRC head: 9128
LRC tail: 9288ジョブ3514が投入された一方で、LRCのHeadがTailに追いついていません。これは、CCSジョブが投入された後に、完了処理まで進まなかった状態と繋がってるようで。CCS障害の後には、BCS側でもリセットが発生しましたと捉えられるそうです。
Fault response: Unsuccessful -ENOENT
Engine reset: engine_class=bcs, logical_mask: 0x1, guc_id=6, state=0x289-ENOENTは、ページフォルトを処理する時点で対象VMがすでに閉じられている場合に発生します。
つまり、CCS障害によってアプリケーションやVMの終了処理が始まり、その後に遅れて届いたBCSページフォルトが、すでに閉じられたVMへ届いた可能性があります。Luna曰く、今回の障害は、次のような連鎖として整理できるとのこと。
GPU内部のバッファまたは同期処理に異常が発生
↓
BCSが存在しないGPU仮想アドレスを読み取る
↓
Xeのページフォルト処理が失敗し、-EINVALを返す
↓
CCSコンテキストがリセットされる
↓
llama-serverのジョブが完了せず、Timedout jobになる
↓
VM終了または後処理が始まる
↓
遅れて届いたページフォルトが-ENOENTになる
↓
BCSもリセットされる同じGPU仮想アドレスが異なるASIDで再発している点も、内部バッファ管理の問題を疑われるそう。
ASID 580:
0x0000d556aa411000
ASID 1236:
0x0000d556aa411000ASIDが異なるため、同じVMの同じページとは断定できませんが、異なるVMで同じアドレスがBCSのnot-present faultとして現れているため、アプリケーションデータではなく、ランタイム内部のリングバッファ、セマフォバッファ、コマンドバッファ、タイムスタンプバッファなどが関係している可能性があります。
この点は、Intel Compute RuntimeのIssue #948で報告されている内部同期バッファの常駐管理問題とも一致します。ただし、今回の環境でFaulted Addressがどのバッファに対応するかまでは確認できていません。
どういう理由で回避策が有用だったか
今回、次の環境変数を設定してllama.cppを起動すると、動作が大きく改善しました。これは、一連の流れの中でNateHag氏が説明してくれてた話で、llama.cppの中でも同じような内容が説明されていました。
export SYCL_UR_USE_LEVEL_ZERO_V2=0この設定は、SYCLからLevel Zeroドライバへ接続するアダプター経路を変更するものです。Xe2アーキテクチャを持つB70の場合、通常はV2という新しいアダプタを使用するよう設計されているのですが、その経路ではなく、古いアーキテクチャ向けのLevel Zeroアダプター経路を使用する構成にするのがこの設定です。
今回は、Kernel-7.0.0-31への切り替え後は、ハードウェア、カーネル、GuCファームウェアを変えずに、この設定だけを変更しました。その結果、llama.cppを動かしてみると結構ビックリすることが起きましてですな・・・。
- ベンチマーク性能が大幅に向上した（Muse Glimmerの出力スループットが20tps→40tpsぐらいに）
xpu-smiでGPU利用率が100%まで上がるようになった（従来は22%で頭打ちしてた）- ベンチマーク処理が継続した（途中停止したGPUが停止しなくなった）
- CCS、BCSリセットが直ちには発生しなくなった（ベンチマークテスト中もエラーメッセージは全く出ていない）
xpu-smiの利用率だけでは、表示経路の違いによる可能性も残ります。しかし、実際の性能向上とベンチマークの継続が同時に確認できたため、単なる監視表示の問題だけでは説明しにくい結果です。Luna曰く、この設定を入れたことにより、次のような処理経路の一部が変わった可能性があるとのこと。
- コマンドリストの投入
- イベントの生成と待機
- コマンドキューの同期
- Direct Submission
- セマフォバッファの管理
- GPU仮想アドレスのバインド
- メモリ追い出し後の再バインド
- GPU実行完了の通知
今回の回避策は、ユーザー空間からGPUへ仕事を投入する経路を変え、問題を起こしていた可能性のあるV2経路を避けています。
V2アダプター経路
↓
B70上で同期、常駐、イベント、バッファ再利用のどこかが破綻
↓
GPU仮想アドレスの不整合
↓
BCSページフォルト
↓
CCS、BCSリセット
SYCL_UR_USE_LEVEL_ZERO_V2=0
↓
別のアダプター経路を使用
↓
問題の経路を回避
↓
GPU処理とベンチマークが継続ただし、ここから「Level Zero V2だけが根本原因だった」と断定することはできないようで、より正確には、V2アダプター経路、Intel Compute Runtime、Xe KMD、GuCファームウェア、llama.cppのメモリ管理が組み合わさった条件で障害が発生し、Legacy経路がその条件を回避したと考えるべきであるとのこと。
今後につながるまとめ
今回の問題は、個別GPUの物理故障よりも、BMG世代GPUの計算ランタイムとXe、GuCの境界で起きる論理障害である可能性が高いです。
ただし、PCIe、IOMMU、VRAM容量、カード個体差を完全に除外したわけではありません。
現時点での原因候補は、次の順番です。
- GPU内部の同期バッファまたは常駐管理の不整合
- Level Zero V2アダプターとBMG向けXe、GuCの相互作用
- Xeのページフォルト処理とコンテキストリセットの競合
- llama.cppやIntel Compute Runtimeによるバッファ再利用
- oneCCLや複数GPU間通信の影響
- PCIe、IOMMU、個別ハードウェアの問題
今回の調査で得られた教訓は、カーネルログに現れた最終的なリセットだけを見てはいけないということです。
Timedout job
Engine resetだけを見ると、GuCスケジューラの問題に見えます。しかし、障害の前には次のログが出ていました。
FaultType: 0
AccessType: 0
EngineClass: 3 bcs
Fault response: Unsuccessful -EINVALこの先行ログを含めることで、問題が単なるジョブタイムアウトではなく、GPU仮想メモリと内部バッファ管理に関係している可能性が見えてきました。
また、同じカーネルでもユーザー空間のアダプター経路を変更するだけで、性能と安定性が改善しました。
このA/B結果は、問題の所在がハードウェアだけではなく、ユーザー空間ランタイムとカーネルドライバの境界にあることを示す重要な材料です。
当面の実用的な回避策は、次の設定です。これをllama.cpp実行時に、他の環境変数と同じように突っ込むことでどうやらある程度改善は効きそうにみえます。
export SYCL_UR_USE_LEVEL_ZERO_V2=0ただし、これは正式な修正ではないのでしょうし、今後のランタイム更新で挙動が変わる可能性があるでしょうね。
今回の件は、ハードウェアが壊れたというより、新しいGPUアーキテクチャに対する複数のソフトウェア層が、特定の計算負荷で同じGPU仮想メモリ状態を正しく共有できなかった問題として一種の論理障害として暑かった方が良いみたいです。それにしても、ハード故障の類いじゃなくてほんとに良かった。（お仕事だとハードウェア保守にまわせば良い話になるのでそっちの方が幸せだった・・・ってなりそうな気もしますがううむ）
参照した公開報告
コメント