讀懂 NVIDIA Xid 錯誤碼：GPU 除錯的第一堂課 | GPU 除錯系列 #1

本文寫給還沒接觸過 NVIDIA GPU 維運的讀者，從 Xid 是什麼、去哪裡找、怎麼讀開始，並以掉卡（Xid 79, GPU has fallen off the bus）與 ECC Error（Xid 48/63/64/92/94/95）兩個最常見的案例，說明 GPU 基本除錯的判斷方式，以及回報問題時該準備什麼。資料中心常見的 Xid 錯誤碼與 NVIDIA 官方建議動作，整理在文末的速查表供查閱。

一、Xid 是 GPU 的「黑盒子」警報

Xid 是 NVIDIA GPU 驅動的錯誤代碼。當 GPU 出狀況，例如程式突然出現 CUDA error、用 nvidia-smi（NVIDIA 驅動附的 GPU 狀態查詢工具）看少了一張卡、或整台機器卡住，NVIDIA 驅動（Linux kernel module nvidia，log 前綴為 NVRM）會在 Linux 的 kernel log（作業系統核心的訊息紀錄）寫下一行 Xid 訊息，記錄出事的是哪一張卡、當時是哪個程式在使用它、以及發生了哪一類錯誤。可以把它理解成 GPU 的黑盒子：出事的那一刻，離硬體最近的第一手紀錄就在這裡，比應用程式自己印出來的錯誤更直接、也更不容易失真。一行典型的 Xid 訊息如下：

NVRM: Xid (PCI:0000:5a:00): 79, pid=12345, name=python, GPU has fallen off the bus.

一行訊息裡有四個關鍵欄位：

NVIDIA 官方對 Xid 的定義是：驅動輸出到作業系統 kernel log 的錯誤報告，可能代表硬體問題、NVIDIA 軟體（驅動／firmware）問題、或使用者應用程式問題。¹這個定義本身就點出了 Xid 除錯的難處：同一個編號背後，可能是硬體、驅動、應用程式三種性質完全不同的根因。因此在查表之前，先建立三個觀念：

1. Xid 是症狀的編號，不是診斷。 同樣一個 Xid 79，根因可能是電源、PCIe 訊號、主機板韌體或 GPU 本體，必須靠前後文判斷。
2. 不是每個 Xid 都代表硬體故障。 Xid 13/31/43/45 絕大多數源自應用程式本身的 bug（例如陣列越界）；Xid 63/92/154 則屬於資訊型訊息。²
3. Xid 要看「組合」與「時間序」。 例如 Xid 48 之後接著 63 還是 64、伴隨 94 還是 95，決定了處置方式是重啟程式、重置 GPU、還是重開整台機器。

二、第一步：找到 Xid 訊息

Xid 只會出現在 kernel log，所以第一步永遠是查 kernel log。最常用的指令是 dmesg，它會印出這次開機以來 kernel 的所有訊息，再用 grep 過濾出含有 xid 的行即可：

# 最直接：kernel ring buffer（-T 顯示人類可讀時間）
sudo dmesg -T | grep -i xid

# 用 journald 看 kernel log；-b -1 可以看「上一次開機」的紀錄（掉卡重開後很有用）
sudo journalctl -k -b | grep -i xid
sudo journalctl -k -b -1 | grep -i xid

# 傳統 syslog 檔案
grep -i xid /var/log/messages     # RHEL / Rocky
grep -i xid /var/log/syslog       # Ubuntu / Debian

# 看 Xid 前 30 行、後 5 行的上下文
sudo dmesg -T | grep -i -B30 -A5 "xid"

兩個實務提醒：

• Xid 那一行只是入口，線索在上下文。 出事前的幾十行內，常有更關鍵的訊息：PCIe 錯誤（AER）、溫度警告、或是另一張 GPU 幾乎同時也報錯。這些往往比 Xid 編號本身更能指向根因，所以查 Xid 時務必連前後文一起看。
• dmesg 是環形緩衝區，重開機後就不存在了。 掉卡後最常見的處置是重開機，而重開機同時也銷毀了第一現場。重開機之前，先把 Xid 訊息與前後文複製保存；正式環境則應該把 kernel log 集中收集（例如讓 journald 開啟 persistent storage），事後才有資料可查。³

找到 Xid 之後，接下來用兩個最常見的故障，說明怎麼判讀與處置。

三、除錯案例一：掉卡（Xid 79, GPU has fallen off the bus）

「掉卡」指的是 GPU 從 PCIe 匯流排上消失、驅動無法再與它通訊。可以想像成使用中的 USB 隨身碟突然被拔掉：作業系統只知道裝置不見了，正在使用它的程式全部出錯。這是 GPU 維運最常遇到的故障之一，也是最難一次定位根因的一種：症狀只有一種，原因卻可能落在電源、訊號、韌體到 GPU 本體的任何一層。

3.1 症狀長什麼樣

# dmesg：Xid 79 本體，後面通常跟著 crash dump 提示
NVRM: Xid (PCI:0000:ca:00): 79, pid='<unknown>', name=<unknown>, GPU has fallen off the bus.
NVRM: GPU 0000:ca:00.0: GPU has fallen off the bus.
NVRM: A GPU crash dump has been created. If possible, please run
NVRM: nvidia-bug-report.sh as root to collect this data before
NVRM: the NVIDIA kernel module is unloaded.

# nvidia-smi：整體報錯、或直接少一張卡
Unable to determine the device handle for GPU 0000:ca:00.0: Unknown Error
$ nvidia-smi --list-gpus | wc -l      # 比預期少 1

# lspci：裝置消失，或 config space 讀回全 0xFF
ca:00.0 3D controller: NVIDIA Corporation Device 2330 (rev ff)
    !!! Unknown header type 7f

在應用程式端，對應的症狀通常是 CUDA error: unspecified launch failure、NCCL 的 unhandled cuda error，或是訓練直接卡住直到 timeout。

3.2 可能的原因

NVIDIA 對 Xid 79 的定義是：驅動嘗試透過 PCIe 存取 GPU，卻發現 GPU 不可達。最常見的原因是 PCIe 連線的硬體故障導致 link 中斷，也可能是 GPU 本身的硬體故障或驅動問題。¹綜合官方文件、NVIDIA 論壇與各家雲端的經驗，根因大致可分為五類^{4 5}：

3.3 排查步驟（建議照順序）

1. 先界定範圍：影響幾張卡？只發生在這一台，還是同型號的機器都有？最近是否更換過驅動、韌體或 BIOS？如果同一台機器上多張 GPU 同時掉卡，應優先懷疑共用的電源或主機板，而非 GPU 本身。
2. 檢視 dmesg 前後文：Xid 79 之前的 30 行內，是否出現 PCIe AER 錯誤、溫度警告或 Xid 119/120？這些線索會直接對應到上表的類別。
3. 確認 GPU 是否還在匯流排上：lspci -s ca:00.0 -vv（位址換成 Xid 訊息裡的 PCI BDF）；若顯示 rev ff 或裝置已消失，代表 GPU 已經不在 PCIe 匯流排上。此時 nvidia-smi -r（GPU reset）不會有效果，因為驅動已經無法與裝置通訊，只剩重開機一途。
4. 重開機前先保留證據：執行 sudo nvidia-bug-report.sh 收集 crash dump 與完整 log（第五節說明），然後重開機。⁴雲端 VM 的對應做法是 reboot VM；反覆發生時，AWS 建議以 stop/start 遷移到新的實體主機，GCP 建議刪除並重建 VM，仍無法解決就開 support case。^{6 7}
5. 重開後先驗證，再放回使用：確認 nvidia-smi 看到的 GPU 數量正確，PCIe 鏈路回到預期的速度與寬度（nvidia-smi --query-gpu=index,pci.bus_id,pcie.link.gen.current,pcie.link.width.current --format=csv）。
6. 如果重複發生：重新插拔 GPU 與電源線、更換插槽或線材、更新 BIOS / VBIOS / 驅動、關閉 PCIe 省電功能（ASPM）⁸；仍然復發就執行 NVIDIA Field Diagnostic，帶著報告進入 RMA（送修更換）流程。²

四、除錯案例二：ECC Error（Xid 48 / 63 / 64 / 92 / 94 / 95）

4.1 背景：什麼是 ECC，SBE 與 DBE 差在哪

記憶體並不是絕對可靠的，偶爾會有某個 bit 因為電氣雜訊或宇宙射線而翻轉。ECC（Error Correcting Code）是記憶體的錯誤偵測與更正機制，資料中心 GPU 的記憶體都有這層保護。它把錯誤分成兩種：單位元錯誤（SBE, correctable）可以被硬體自動修正，對工作沒有影響；雙位元錯誤（DBE, uncorrectable）無法修正，GPU 會終止受影響的程式以避免算出錯誤結果，而且需要 reset 才能清除錯誤狀態。⁹所以看到 ECC 相關的 Xid，第一件事是分清楚：這是可修正的還是不可修正的？

4.2 錯誤是怎麼演變的

ECC 相關的 Xid 通常不是單獨出現，而是一串有因果關係的訊息：

SBE 累積過快 ──────────────► Xid 92（資訊型：high single-bit ECC error rate）

DBE 發生 ──► Xid 48（Double Bit ECC Error）
   │
   ├─► 隔離結果（A100 起）：
   │      Xid 94 = 隔離成功，只有該 process 被終止（會伴隨 Xid 45）
   │      Xid 95 = 隔離失敗，整張 GPU 必須 reset
   │
   ├─► 記錄壞掉的位址、準備修復：
   │      Xid 63 = row remapping 已記錄，reset 後生效
   │      Xid 64 = 記錄失敗（備用的 row 用完、或寫入失敗）
   │
   └─► Xid 154 = 總結這次需要 None / GPU Reset / Node Reboot / Drain

Row remapping 是 GPU 記憶體的自我修復機制：每個記憶體 bank 都預留了備用的 row，發現某個 row 壞了，就在下一次 reset 時把它替換掉，之後對軟體完全透明（Ampere 之前的舊卡用的是 page retirement，觀念相同）。所以 Xid 63 只是「已經登記，等 reset 生效」，Xid 64 才代表修不了。⁹

4.3 用 nvidia-smi 確認狀態

$ nvidia-smi -q -d ECC
    ECC Errors
        Volatile                      ← 自上次 driver reload 起的計數
            SRAM Correctable    : 0
            SRAM Uncorrectable  : 0
            DRAM Correctable    : 0
            DRAM Uncorrectable  : 0   ← 非零：去 dmesg 找 Xid 48
        Aggregate                     ← GPU 一生的累計；非零不代表現在有問題

$ nvidia-smi -q -d ROW_REMAPPER
    Remapped Rows
        Correctable Error           : 0    ← 可以忽略
        Uncorrectable Error         : 0    ← 大於 0 就去 dmesg 找對應的 Xid
        Pending                     : No   ← Yes 代表需要 reset GPU 讓 remap 生效
        Remapping Failure Occurred  : No   ← Yes 代表已無法修復，進入 RMA 流程

兩個常見的誤判：Aggregate 計數非零不等於壞卡，那是 GPU 出廠以來的累計值，新機器上非零也很常見，真正要看的是 Volatile；Correctable 的 remap 不需要處理，需要關注的是 Uncorrectable、Pending 與 Remapping Failure 這三個欄位。¹⁰

4.4 決策表：看到什麼、該做什麼

關於 GPU reset：sudo nvidia-smi -r -i <index> 可以在不重開機的情況下清除 GPU 的錯誤狀態，是處理 DBE 的標準動作。它需要 root 權限，且該 GPU 上不能有任何程式在使用（包含其他正在跑的 nvidia-smi 監控程式）。在雲端 VM 上能否 reset 取決於平台是否開放，不支援時只能重啟 VM。^{2 7}

4.5 什麼時候該送修（RMA）

NVIDIA 的 GPU Memory Error Management 文件把 RMA 門檻寫得很明確，以下任一事件都會觸發 Remapping Failure 旗標，代表這張卡的記憶體已經修不了¹¹：

• 某個 bank 已經有 8 個 uncorrectable rows 被 remap，又要再 remap 一次
• 對一個已經 remap 過的 row 再次 remap
• 整張 GPU 的 uncorrectable remap 總數超過 512 次

最終判定是否符合 RMA 的權威工具是 NVIDIA Field Diagnostic，通常由系統廠商或雲端支援指示何時執行，產出的 fieldiag.log 與 nvidia-bug-report.log.gz 是 RMA 申請的必附檔案。另一個必須記住的規則：只在 ECC 關閉狀態下發生的故障，NVIDIA 不接受 RMA，所以正式環境要全程啟用 ECC（雲端平台預設即為啟用）。¹²

總結

本文簡介了 Xid 錯誤與常見的疑難排解方式：先判斷問題落在哪一層（應用程式／驅動／硬體），再決定該重啟程式、重置 GPU，或重開整台機器，最後把前文收斂成三點：

1. Xid 是 NVIDIA 驅動寫進 kernel log 的錯誤編號：用 dmesg -T | grep -i xid 找、對照文末速查表查，並且永遠連同前後文與組合一起判讀，單一編號無法下結論。
2. 掉卡（Xid 79）先假設硬體問題：檢視 dmesg 前後文，lspci 出現 rev ff 就先收集 bug report 再重開機；重複發生就重新插拔、更新韌體，最後交給 Field Diagnostic 判定是否 RMA。
3. ECC 錯誤看組合決定動作：92/63 單獨出現可忽略或擇期 reset；48+94 只需重啟程式；48+95 或 48+63 要 reset GPU；64 或 Remapping Failure 立刻重開機，達到 RMA 門檻就更換 GPU。

當問題超出自己能處理的範圍、需要交給系統廠商或雲端支援時，NVIDIA 指南建議先整理幾個關鍵資訊：觀察到什麼、何時發生、如何觀察到、是否多台或多張卡同時發生、頻率多高，以及最近系統／驅動／應用程式是否有改動²。包含：

• OS、kernel、GPU 型號與驅動版本
• Xid 訊息與前後文（完整的 dmesg 或 journalctl 輸出）
• nvidia-smi -q 的輸出
• 已做過的除錯步驟與結果
• sudo nvidia-bug-report.sh 產生的 nvidia-bug-report.log.gz

附錄：資料中心常見 Xid 速查表

NVIDIA 在新版 Xid 文件中提供了 Xid Catalog，針對 Ampere 以後的 GPU（A100 / H100 / B200）標出每個 Xid 的「立即動作」，例如 IGNORE、RESTART_APP、RESET_GPU、RESTART_BM、CONTACT_SUPPORT。¹³下表以此為骨幹，加上 GPU Debug Guidelines 與各家雲端文件的建議^{2 7 6}，整理最常遇到的 Xid（Volta 及更早的 GPU 請查 archive 版文件¹⁴）：

幾個「建議動作」對應的官方分類：

• 重啟程式（RESTART_APP）：問題在應用程式，重啟即可，不需要動 GPU。
• reset GPU（RESET_GPU）：sudo nvidia-smi -r -i <index>，需要 root、且該 GPU 上不能有任何程式在使用。
• 重開機（RESTART_BM）：重開整台機器；雲端環境對應的動作是 reboot VM。
• 找廠商（CONTACT_SUPPORT / RUN_FIELDDIAG）：執行 NVIDIA Field Diagnostic、準備 RMA，或聯繫系統廠商／雲端支援。

Xid 154 值得單獨說明。從 R565 驅動（CUDA 12.7）起，驅動會在其他 Xid 之後補上一行像 Xid 154 GPU recovery action changed from 0x0 (None) to 0x2 (Node Reboot Required) 的訊息，直接標示這次事件需要的恢復層級。同樣的資訊也會出現在 nvidia-smi -q 的 GPU Recovery Action 欄位，等於驅動直接給出處置建議；有這一行時，以它為準。¹

附錄：名詞小抄

參考資料