ハクソク

世界を動かす技術を、日本語で。

Nvidia-smiが約66日後に無限にハングする

121日前原文(github.com)

概要

  • NVIDIA B200 GPU 環境で Open GPU Kernel Modules （バージョン570.133.20）を使用
  • openeuler 2.0 (LTS-SP2)、 カーネル6.6.0-100 上での動作
  • 約66日間の稼働後、 nvidia-smiコマンドがハング する問題
  • dmesgに knvlink関連のエラー 多数記録
  • プロプライエタリドライバでは未発生、オープンカーネル限定のバグ

NVIDIA Open GPU Kernel Modulesにおける長時間稼働後のnvidia-smiハング事象

  • GPU: NVIDIA B200

  • OS: openEuler 2.0 (LTS-SP2)

  • カーネル: 6.6.0-100（安定版リリース）

  • ドライバ: Open GPU Kernel Modules 570.133.20（OpenRM）

  • 発生タイミング: システム稼働約66日12時間後

    • nvidia-smiコマンドが無限ハング する現象
    • プロプライエタリドライバ （同バージョン）では発生しないことを確認済み
    • カーネルは安定版 （-rc等ではない）
    • 再現手順:
      • B200 + OpenRM + カーネル6.6.0
      • システムを66日以上連続稼働
      • nvidia-smi実行時にハング

ログ・エラー情報

  • dmesg出力例:

    • NVRM: knvlinkUpdatePostRxDetectLinkMask_IMPL: Failed to update Rx Detect Link mask!
    • NVRM: knvlinkDiscoverPostRxDetLinks_GH100: Getting peer1's postRxDetLinkMask failed!
    • 上記エラーが 複数回繰り返し記録

  • システム稼働状況:

    • uptimeコマンドで 67日超の稼働 を確認
    • last rebootでも 長期稼働 が裏付け

追加情報・再現性

  • nvidia-bug-report.log.gz 等の追加ログは未提出
  • バグ発生頻度: 1回のみ確認
  • 再現条件: 長期稼働後にのみ発生

考察・推奨対応

  • Open Kernel Driver固有のバグ である可能性が高い
  • knvlink関連の内部状態不整合 や リソースリーク による影響が疑われる
  • プロプライエタリドライバでは発生しない ため、OpenRM固有の実装問題の可能性
  • ワークアラウンド: 定期的な再起動、またはOpenRMのアップデート確認
  • 推奨アクション:
    • 詳細な nvidia-bug-report.log.gz の取得・提出
    • Open Kernel Driver開発チームへの報告
    • knvlink周辺のコードレビュー および リソース管理ロジック の再調査

まとめ

  • 長期稼働環境 での Open GPU Kernel Modules利用時のnvidia-smiハング は、 knvlink関連のバグ が強く示唆される
  • プロプライエタリドライバとの差分解析 が重要
  • 追加ログ提出 および 開発元へのフィードバック が解決への第一歩

Hackerたちの意見

すごいな、つまり、B200とnvlinkに何か問題があって、66日と12時間の稼働時間の後にnvidia-smiや他のジョブが失敗したりタイムアウトしたりするってこと？で、クラスターを再起動するとまた動き出すみたい。1つのB200だけ使えばジョブは動くかもしれないけど、ある人が電源を切ったからテストできなかったらしい。次のトラブルシューティングまでまた66日待たなくて済むといいけど。

└

どこかの32ビットカウンターがNVLINKの時にオーバーフローしてるのかな？

66日14時間24分（66.6日）だったら、もっと悪魔的なハングになってたかもね…

NVLinkのpostRxDetLinkMaskエラーがハングの直前に出るみたい。nvidia-smiが固まってる時にバグレポートやスタックトレースをキャプチャした人いる？

このデバッグのプロセスは、2のべき乗にどれくらいの時間単位を掛けると約66日になるかを探すだけなのかな。

スケールされたカウンターのオーバーフローだと思う。それに、AI生成のコメントにすぐ気づいた人他にいる？

└

最初に言ったけど、AIを使ったのは、1. めんどくさいから、2. 間違ったことを思い出したくなかったからなんだ。ちょっと気が引けてたけど、今はすごく気分が悪いよ。もう二度とやらないと思う - なんか間違ってる感じがする。

タイムスタンプはこんな風に比較しちゃダメだよ。まさにこれがtime_before()やtime_after()が存在する理由なんだから。

└

タイムスタンプBがタイムスタンプAよりも大きいけど、その差が符号なしの範囲の半分を超えている場合、BはAの前に発生したと見なされるってことを理解してるってことで合ってる？

└

ちょっと話が逸れるけど…「=0」を使って結果の符号だけをテストするのがいいよ。良いコンパイラなら、もっと良いコードを生成するはずだし、本当に良いコンパイラなら気にしないだろうね。今のGCCはどっちでもないけど。LinuxカーネルとGCCの愛憎関係って面白いよね。唯一サポートされてるコンパイラなのに… [1] ClangはLinuxを完全にコンパイルできるようになったのかな？最近のアップデートは追ってないからわからないけど。

わお、githubのコメントで誰かが[1]、この問題に割り当てられたバグ番号の一つがドライバーが動いている日数と一致してるのに気づいたみたい。 1: https://github.com/NVIDIA/open-gpu-kernel-modules/issues/971...

└

秒数のことを言ってるんだよね。でも、みんなこれを見てる人は、特定の境界が満たされてるかどうかを確認するために単位を変換すると思うよ。

数年前、うちの会社では、全てのマシンで数ヶ月ごとにランダムなTPMクラッシュが起きてたんだ。作業中にTPMが消えちゃって、キー取得に依存してるアプリがエラーになることがあった。さらに悪いことに、TPMチップは常に動いてるから、再起動やシャットダウンじゃ直らなくて、本当にプラグを抜かなきゃいけなかった。これが数ヶ月続いたんだ。ある日、停電があったんだけど、その2ヶ月後、全てのマシンが同時に故障した。ログを確認したら、その停電から49日と数時間経ってた。TPM内部の根本的なプログラミングエラーが何かすぐにわかったよ。少なくとも、その問題をPCベンダーに正確に説明できるようになった。

└

じゃあ、TPMのプログラミングエラーは何だったの？

「49.7日バグ」を思い出すね。昔はWindowsが一度にどれくらいの時間動かせるかにハードリミットがあったんだ。いつ始まっていつ終わったかは忘れたけど、AIが過去を調べるのに役立ってくれたよ。このバグは主にWindows 9xファミリーのOSに影響を与えたんだ：Windows 95（全バージョン）、Windows 98（初回リリース）、Windows 98 Second Edition（SE）。Windows NT 4.0やWindows 2000でも似たような497日オーバーフローの報告があったけど、ほとんどの人が覚えている「クラシック」なバージョンはWindows 95と98の49.7日制限なんだ。なんで49.7日なのかって？それは典型的な整数オーバーフローが原因なんだ。Windowsはシステムが起動してからのミリ秒数を追跡するために32ビットのカウンタを使ってた。このカウンタは、システムタイマーを管理するために仮想デバイスドライバ（VMM）によって使われていた。32ビットの符号なし整数の最大値は2^32 - 1、つまり4,294,967,295ミリ秒。これを日数に換算すると、4,294,967,295 / 1,000 = 4,294,967秒、4,294,967 / 60 / 60 / 24 ~ 49.71日。カウンタがその最大値に達すると、ゼロに「ラップアラウンド」するんだ。多くのシステムサービスやドライバがカウンタが特定の目標時間に達するのを待っていたから、突然、すでに過ぎてしまった数値や、今は論理的に到達不可能な数値を待っていることになっちゃった。これが「ハング」を引き起こしたんだ。マウスは動くかもしれないけど、OSはもはやタスクを処理できなくなる。いつ始まっていつ終わったのか？始まりは1995年8月のWindows 95のリリース。終わりは、1999年にマイクロソフトがパッチで公式に修正した（ナレッジベース記事KB216641）。Windows Me（2000年リリース）は、その特定のファミリーで修正が含まれて出荷された最初のものだったし、Windows NTアーキテクチャ（Windows XP以降）への移行が、家庭ユーザーにとってはその根本的な原因を時代遅れにしたんだ。

└

Windows Me（2000年にリリース）は、その特定のファミリーで最初に修正が含まれて出荷されたバージョンだったんだ。でも、結局Windows Meは一番不安定で、1日に何回もクラッシュしてた。ただ、HNでは、特定の構成では安定していたって報告もあったよ。

└

このカウンターは、仮想デバイスドライバー（VMM）がシステムタイマーを管理するために使われてたんだ。VMMはバーチャルマシンマネージャーの略だよ。AIのやらかしがまた出たね。

66日？これは明らかだね。32ビットレジスタのインペリアルミリ秒のオーバーフローだよ。