GB10マシンがHDMIをつなぐと再起動し、GPUも消えた。犯人はファームウェアではなくカーネルだった

dgx spark（GB10 MSI EdgeXpert）で、GPUが消え、HDMIをつなぐと勝手に再起動するようになった。原因を探す過程をまとめる。

結論から書くと、犯人はカーネル7.0.0-1024-nvidiaだった。7.0.0-1019-nvidiaに戻すと、HDMIをつないでも再起動しなくなり、GPUも安定した。途中でいちばん疑ったファームウェアは、冤罪だった。

事件の発端

このマシンでは、埋め込みモデルの追加学習を3日ほど回していた。学習と評価が終わったあとに一度電源を落とし、2分ほどして入れ直すと、GPUが見えなくなっていた。

$ nvidia-smi
No devices were found

カーネルのログには、ドライバを読み込んだ直後から次のエラーが出ていた。

NVRM: Xid (PCI:000f:01:00): 169, c287d000 94000000
NVRM: Xid (PCI:000f:01:00): 119, Timeout after 6s of waiting for RPC response from GPU0 GSP! Expected function 4097 (GSP_INIT_DONE)
NVRM: ksec2PrepareBootCommands_GB20B: SEC2 secure boot partition timed out.
NVRM: RmInitAdapter: Cannot initialize GSP firmware RM
NVRM: GPU 000f:01:00.0: RmInitAdapter failed! (0x62:0x65:2028)

GPUのファームウェア（GSP）が起動せず、ドライバは再試行を1,000回以上繰り返していた。前の起動では学習が最後まで正常に回っていたので、GPUそのものが急に壊れたとは考えにくい。

調査はClaude Codeに任せた。ログを読ませ、仮説を立てさせ、ひとつずつ潰していった。

容疑者1：ドライバとカーネルの更新

GPUが急に見えなくなったときにまず疑うのは、更新である。しかし、直近3回の起動を比べると、カーネル（7.0.0-1024-nvidia）もドライバ（580.178.04）も同じ版だった。前の起動では同じ組み合わせで学習が回っていたので、ここで一度シロと判定した。

この判定は「直近3回」しか見ていなかった。これが後で効いてくる。

容疑者2：GPUのクロック制限

このマシンは熱が気になって、起動時にGPUのクロックを2,000MHzに制限するsystemdのサービスを入れていた。起動のたびにGPUに触る処理なので疑ったが、ログの時刻を見るとアリバイがあった。

時刻	出来事
21:25:37	GPUのエラー（Xid 169、GSPの時間切れ）
21:27:13	クロック制限のサービスが起動し、「No devices were found」で失敗

クロック制限は、GPUが倒れたあとに現場に来ていた。シロ。

容疑者3：ファームウェアの更新

fwupdmgr get-historyで更新の履歴を見た。最初に目に入ったのは8月のEmbedded Controllerの更新だけで、関係なさそうに見えた。

同じエラーの事例をNVIDIAのフォーラムで探すと、いくつか見つかった。

普通の再起動では直らず、電源アダプタを抜いて30秒以上待つと直った、という報告がある。電源アダプタがつながっている間は、GPUの制御部が壊れた状態を保ってしまうらしい。
一方で、電源を抜いても、OSとファームウェアを入れ直しても直らず、修理（RMA）になった例もある。

電源アダプタを抜いて1〜2分待ち、起動し直すと、GPUは戻った。ひとまず事件は解決した、はずだった。

第二の事件：HDMIをつなぐと再起動する

HDMIケーブルをつなぐと再起動を繰り返すことには気づいていて、今のファームウェアが安定していないのではと疑っていた。

履歴を全部見ると、8月の更新とは別に、USB-C PD（給電の制御）のファームウェアが10/31に502から522に上がっていた。最初に見たときは、出力の先頭しか読んでいなかったので見落としていた。いちばん新しい変更で、時期も合う。最有力の容疑者である。

$ sudo fwupdmgr downgrade <USB-C PDのDevice ID>   # 522 → 502

502に戻して再起動し、HDMIをつないだ。再起動した。

ファームウェアは関係なかった。

ログに何も残らない再起動

この時点で、23分間に8回起動していた。それぞれの起動の終わり方を見ると、2種類に分かれた。

3回は、systemdが順にサービスを止めて終わっている。ファームウェアを戻すために自分で再起動した分である。
4回は、止まる手順が一行もなく、途中でぷつりと切れている。HDMIによる再起動はこちらである。

切れる直前のカーネルのログには、HDMIの話もGPUのエラーも出ていなかった。最後の行は、起動のたびに出る決まった表示だけだった。OSが何かを記録する前に、もっと下の層（ファームウェアや電源の制御）で本体がリセットされている。

しかも、この23分の間にGPUが起動しなかった2回は、どちらもこのリセットの直後の起動だった。リセットされたGPUは、電源アダプタを抜くまで壊れた状態を引きずる。

真犯人：カーネル 7.0.0-1024-nvidia

フォーラムをもう一度探すと、立ったばかりのスレッドが見つかった。タイトルは「Any use of the HDMI (TMDS) output causes a hard reset on kernel 7.0.0-1024-nvidia」。ASUSのGB10マシンでの報告で、症状がそのまま同じだった。

HDMIのモニタをつないで起動すると、65〜100秒後にハードリセットされ、それを繰り返す。起動したあとに挿すと、数秒でリセットされる。
リセットの前に、ログには何も残らない。
次の起動で、ACPIのBERT（前の起動で起きたハードウェアの誤りの記録）にcorrectedの記録が1件出る。
7.0.0-1019-nvidiaに戻すと直った、という人が複数いる。

自分のマシンでも、起動ごとのカーネルの版とBERTの記録を並べた。

起動した時刻	カーネル	BERTの記録
10/31 14:57	7.0.0-1019-nvidia	なし
10/31 15:12〜15:30（13回）	7.0.0-1024-nvidia	毎回あり
11/01 21:25	7.0.0-1024-nvidia	あり
11/01 22:59〜23:09（5回）	7.0.0-1024-nvidia	毎回あり

BERTの記録の中身もフォーラムと同じだった。

BERT: Error records from previous boot:
[Hardware Error]: event severity: corrected
[Hardware Error]:   section type: unknown, 3c1e3f4b-1e1a-43df-af28-59820e958e3c

決め手は1行目と2行目の間である。カーネルが1024になった10/31の15:12から15:30まで、1分半おきに13回起動し直していた。

容疑者1を「直近3回が同じ版だから」でシロにしたのが間違いだった。直近3回はすべて1024で、比べる相手も1024だった。1024でも、学習は2日間問題なく回っていた。

そして、USB-C PDのファームウェアが入ったのは10/31の15:10で、カーネル1024で初めて起動したのはその直後の15:12だった。二人の容疑者が同じ時刻に現場にいたので、片方が冤罪になった。

1019に戻す

7.0.0-1019-nvidiaのカーネルと、それ用のドライバ（同じ580.178.04）はまだ残っていた。GRUBで1019から起動するように固定する。

$ echo 'GRUB_DEFAULT="Advanced options for DGX OS GNU/Linux>DGX OS GNU/Linux, with Linux 7.0.0-1019-nvidia"' \
    | sudo tee /etc/default/grub.d/99-kernel-1019.cfg
$ sudo update-grub

GRUBの項目は、IDでも名前でも指定できる。IDは長く、表示を切り詰めると途中で読めなくなるので、名前で指定した。区切りの>は、サブメニューとその中の項目をつなぐ。

設定が入ったかを確かめるときに、ひとつ罠がある。

$ sudo grep -n "set default" /boot/grub/grub.cfg
24:   set default="${next_entry}"
29:   set default="Advanced options for DGX OS GNU/Linux>DGX OS GNU/Linux, with Linux 7.0.0-1019-nvidia"

set defaultは2回出てくる。1回目は「次の1回だけ別の項目で起動する」ための行なので、grep -m1で最初の行だけを見ると、設定が入っていないと誤解する。見るのは2回目の行である。

リセットでGPUが壊れた状態を消すため、シャットダウンして電源アダプタを1〜2分抜いてから起動した。

$ uname -r
7.0.0-1019-nvidia
$ nvidia-smi --query-gpu=name,driver_version --format=csv,noheader
NVIDIA GB10, 580.178.04

GPUのエラーは0件、BERTの記録もなし。HDMIをつなぐと、Xorgがモニタを認識した。

NVIDIA(GPU-0): BenQ EW3270U (DFP-0): connected
NVIDIA(GPU-0): BenQ EW3270U (DFP-0): Internal TMDS

画面が映り、そのまま再起動しなかった。

最後に、冤罪だったUSB-C PDのファームウェアを522に戻した。こちらも問題なく動いている。

振り返り

症状が始まった時刻に、何が変わったかを見る。「直近の起動どうしで同じか」を比べても、全部が壊れた後なら差は出ない。今回は、起動ごとのカーネルの版とBERTの記録を並べた表が決め手になった。
同時に入った更新は、片方だけ見ると誤認する。カーネルとファームウェアが同じ再起動で入れ替わっていた。
ログに何も残らないこと自体が手がかりになる。OSのログが途中で切れていて、次の起動でBERTに記録が出るなら、OSより下でリセットされている。
GPUのGSPが起動しないときは、電源アダプタを抜く。普通の再起動では直らなかった。

7.0.0-1024-nvidiaの不具合は、NVIDIAからの回答も直った版もまだ出ていない。直った版が出るまで、1019で固定しておく。