Log for Ubuntu 台灣社群
使用 NVIDIA 開源核心驅動時，系統運作約 66 天後 `nvidia-smi` 會無限期卡住不回應 （★ 100 分）
GitHub 上 NVIDIA `open-gpu-kernel-modules` 的一則問題回報指出，使用開源核心驅動（OpenRM）時，B200 GPU（圖形處理器，Blackwell 架構）在系統連續運作約 66 天 12 小時後，`nvidia-smi`（NVIDIA 的 GPU 狀態與管理指令）會無限期卡住不回應。回報者環境為 openEuler 2.0（LTS-SP2）與 Linux 核心 6.6.0，驅動版本 570.133.20；並特別確認同版本的 NVIDIA 專有驅動程式不會發生，顯示問題更可能落在開源核心驅動路徑。
故障發生前後，系統記錄會反覆出現 NVRM（NVIDIA 核心驅動訊息前綴）與 NVLink（NVIDIA GPU 高速互連）相關錯誤，像是 `knvlinkUpdatePostRxDetectLinkMask_IMPL` 與 `knvlinkDiscoverPostRxDetLinks_GH100` 無法取得 peer 的 `postRxDetLinkMask`。回報者補充，當狀況發生時不只 `nvidia-smi`，包含 `nvidia-smi topo -p2p r`、`nvidia-smi -L` 等查詢都會變得極慢甚至無法正常完成，`nvidia-bug-report.sh`（用於蒐集除錯資料的腳本）也會變得非常慢；雖然已啟用 persistence mode（常駐模式，避免 GPU 反覆初始化），仍需要重開機才能恢復。
後續多位使用者在不同環境重現：有人在 Ubuntu 24.04、核心 6.8、驅動 580.82.07／580.105.08 也遇到約 66～67 天後 `nvidia-smi` 無回應，且因 Zabbix（監控系統）定期執行 `nvidia-smi` 造成負載飆升、節點不穩定而被迫重開機；也有人嘗試在出問題節點執行 8-GPU 的 HPL（High Performance Linpack，常見超算效能測試）工作負載，透過 NGC container（NVIDIA GPU Cloud 容器映像）與 Singularity（HPC 常用容器執行環境）啟動但失敗，推測與跨 NVLink 通訊中斷有關。NVIDIA 協作者回應表示研判「跨 NVLink」在該時間點後失效、但單卡理論上仍可能可用，並以內部 NVBug 編號 5746052 與 5607938 追蹤；之後也明確確認 580 系列同樣受影響，修正正在進行但沒有時程，且 NVBug 編號不對外公開。另有開發者提出更具體的可能成因：Linux 的 `jiffies`（以核心 tick 計數的時間基準）在特定 `CONFIG_HZ=750` 的設定下，計時換算可能剛好在約 66.5 天發生回捲（wrap），建議改用 `ktime_get_raw_ts64` 這類較安全的時間來源，並指出 PR（Pull Request，合併請求）#1014 可能就是修正方向。
Hacker News 討論多半把焦點放在「66 天」這種過於固定的觸發條件，直覺聯想到典型的計數器溢位或時間回捲：有人提到 32-bit 計數器若以毫秒計會在約 49.7 天溢位（也讓人聯想到 Windows 95 的 49 天問題），也有人建議直接找「某個時間單位乘上 2 的次方」是否會逼近 66 天。討論串還出現對用語的爭辯：既然有清楚模式就不該叫「隨機」，但也有人認為對不知情的維運者而言，前一天正常、隔天工作開始到處失敗，看起來就像「隨機故障」。此外也有人追問是否有人在 `nvidia-smi` 卡住當下取得堆疊追蹤或除錯資料，好釐清到底卡在 NVLink、驅動鎖或其他等待點；整體氛圍則把它視為「可預期但破壞力極大」的長時間運作陷阱，尤其對大型 B200 叢集會在同一時間窗集中爆發而造成營運風險。
👥 15 則討論、評論 💬
https://news.ycombinator.com/item?id=46750425
GitHub 上 NVIDIA `open-gpu-kernel-modules` 的一則問題回報指出，使用開源核心驅動（OpenRM）時，B200 GPU（圖形處理器，Blackwell 架構）在系統連續運作約 66 天 12 小時後，`nvidia-smi`（NVIDIA 的 GPU 狀態與管理指令）會無限期卡住不回應。回報者環境為 openEuler 2.0（LTS-SP2）與 Linux 核心 6.6.0，驅動版本 570.133.20；並特別確認同版本的 NVIDIA 專有驅動程式不會發生，顯示問題更可能落在開源核心驅動路徑。
故障發生前後，系統記錄會反覆出現 NVRM（NVIDIA 核心驅動訊息前綴）與 NVLink（NVIDIA GPU 高速互連）相關錯誤，像是 `knvlinkUpdatePostRxDetectLinkMask_IMPL` 與 `knvlinkDiscoverPostRxDetLinks_GH100` 無法取得 peer 的 `postRxDetLinkMask`。回報者補充，當狀況發生時不只 `nvidia-smi`，包含 `nvidia-smi topo -p2p r`、`nvidia-smi -L` 等查詢都會變得極慢甚至無法正常完成，`nvidia-bug-report.sh`（用於蒐集除錯資料的腳本）也會變得非常慢；雖然已啟用 persistence mode（常駐模式，避免 GPU 反覆初始化），仍需要重開機才能恢復。
後續多位使用者在不同環境重現：有人在 Ubuntu 24.04、核心 6.8、驅動 580.82.07／580.105.08 也遇到約 66～67 天後 `nvidia-smi` 無回應，且因 Zabbix（監控系統）定期執行 `nvidia-smi` 造成負載飆升、節點不穩定而被迫重開機；也有人嘗試在出問題節點執行 8-GPU 的 HPL（High Performance Linpack，常見超算效能測試）工作負載，透過 NGC container（NVIDIA GPU Cloud 容器映像）與 Singularity（HPC 常用容器執行環境）啟動但失敗，推測與跨 NVLink 通訊中斷有關。NVIDIA 協作者回應表示研判「跨 NVLink」在該時間點後失效、但單卡理論上仍可能可用，並以內部 NVBug 編號 5746052 與 5607938 追蹤；之後也明確確認 580 系列同樣受影響，修正正在進行但沒有時程，且 NVBug 編號不對外公開。另有開發者提出更具體的可能成因：Linux 的 `jiffies`（以核心 tick 計數的時間基準）在特定 `CONFIG_HZ=750` 的設定下，計時換算可能剛好在約 66.5 天發生回捲（wrap），建議改用 `ktime_get_raw_ts64` 這類較安全的時間來源，並指出 PR（Pull Request，合併請求）#1014 可能就是修正方向。
Hacker News 討論多半把焦點放在「66 天」這種過於固定的觸發條件，直覺聯想到典型的計數器溢位或時間回捲：有人提到 32-bit 計數器若以毫秒計會在約 49.7 天溢位（也讓人聯想到 Windows 95 的 49 天問題），也有人建議直接找「某個時間單位乘上 2 的次方」是否會逼近 66 天。討論串還出現對用語的爭辯：既然有清楚模式就不該叫「隨機」，但也有人認為對不知情的維運者而言，前一天正常、隔天工作開始到處失敗，看起來就像「隨機故障」。此外也有人追問是否有人在 `nvidia-smi` 卡住當下取得堆疊追蹤或除錯資料，好釐清到底卡在 NVLink、驅動鎖或其他等待點；整體氛圍則把它視為「可預期但破壞力極大」的長時間運作陷阱，尤其對大型 B200 叢集會在同一時間窗集中爆發而造成營運風險。
👥 15 則討論、評論 💬
https://news.ycombinator.com/item?id=46750425
今天用ubuntu(24.04)出現了3次無預警死當，畫面不是凍住而是全屏的黑、綠、紫，3次當機分別出現這3種覆蓋全屏的顏色。
感覺是顯示的問題，但我的桌機是intel cpu內顯不存在顯卡驅動疑慮，要從哪方向檢查呢？
感覺是顯示的問題，但我的桌機是intel cpu內顯不存在顯卡驅動疑慮，要從哪方向檢查呢？