读懂 NVIDIA Xid 错误码：GPU 故障排查入门 | GPU 调试系列 #1

本文面向刚接触 NVIDIA GPU 运维的读者，从 Xid 是什么、到哪里查找、如何解读讲起，再以掉卡（Xid 79，GPU has fallen off the bus）和 ECC 错误（Xid 48/63/64/92/94/95）这两类常见问题为例，介绍 GPU 故障排查的基本思路，以及向技术支持反馈问题时需要准备的信息。文末还整理了数据中心常见 Xid 错误码与 NVIDIA 官方建议操作，便于随时查阅。

一、Xid 是 GPU 的“黑匣子”警报

Xid 是 NVIDIA GPU 驱动报告的错误码。当 GPU 出现问题，例如应用程序突然报出 CUDA error、nvidia-smi（NVIDIA 驱动附带的 GPU 状态查询工具）无法识别某块 GPU，或者整台服务器无响应时，NVIDIA 驱动可能会在 Linux 内核日志中写入 Xid 消息。负责记录这些消息的是 nvidia 内核模块，日志前缀通常为 NVRM。Xid 日志可以帮助我们定位涉及的 GPU、错误类型，以及驱动能够识别到的相关进程。

可以把 Xid 理解为 GPU 的“黑匣子”警报：它提供了驱动层面的现场信息，是应用程序报错之外的重要排查依据。不过，日志本身不一定能直接说明根因，也不保证每次 GPU 故障都会产生 Xid。下面是一条典型消息：

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

一条消息中有四个关键字段：

NVIDIA 将 Xid 定义为驱动输出到操作系统内核日志的错误报告，它可能与硬件、NVIDIA 软件（驱动或固件），也可能与用户应用程序有关。¹ 这也说明了排查的难点：同一个编号背后可能存在性质完全不同的根因。查表之前，先记住三个原则：

1. Xid 是症状编号，不是诊断结论。 以 Xid 79 为例，原因可能是供电、PCIe 链路、主板固件或 GPU 本体，必须结合上下文判断。
2. 不是每个 Xid 都代表硬件故障。 Xid 13/31 常见于应用程序错误，但也可能与驱动或硬件有关；Xid 43 通常说明应用程序已终止，45 则可能只是清理进程时产生的消息。Xid 63/92/154 主要提供状态或恢复操作信息，也不能仅凭编号就忽略。^{2 3}
3. 需要同时查看 Xid 的组合和时间顺序。 例如 Xid 48 是否伴随 63/64、94/95，以及驱动给出了什么恢复操作，都会影响后续是重启应用程序、重置 GPU，还是重启整台服务器。

二、第一步：查找 Xid 消息

在 Linux 上，排查 Xid 通常从内核日志开始。这些消息也可能被 journald、syslog 或集中日志系统收集。最直接的工具是 dmesg，它读取当前内核环形缓冲区中的消息，再用 grep 筛选包含 xid 的行：

# 读取内核环形缓冲区；-T 将时间戳转换为便于阅读的格式
sudo dmesg -T | grep -i xid

# 通过 journald 查看内核日志；-b -1 表示上一次启动的日志
# 查看上一次启动的日志，需要系统保留了对应记录
sudo journalctl -k -b | grep -i xid
sudo journalctl -k -b -1 | grep -i xid

# 使用传统 syslog 的系统可检查以下文件；路径取决于日志配置
sudo grep -i xid /var/log/messages     # 常见于 RHEL / Rocky Linux
sudo 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 及其上下文。生产环境应启用持久化日志存储或集中收集，例如配置 journald 的持久化存储，确保重启后仍有日志可查。⁴

找到 Xid 后，下面通过两类常见故障说明如何解读和处理。

三、故障排查案例一：掉卡（Xid 79，GPU has fallen off the bus）

“掉卡”是运维中常用的说法，指驱动已无法通过 PCIe 访问 GPU。GPU 可能不再出现在设备列表中，也可能仍有 PCI 条目，但无法正常响应。可以把它理解为正在使用的 USB 设备突然断开：依赖它的程序会报错，系统需要进一步判断是设备、连接还是供电出了问题。Xid 79 的难点就在于症状相似，原因却可能分布在多个环节。

3.1 常见症状

# dmesg：Xid 79 后可能出现崩溃转储提示
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：查询报错，或无法列出预期数量的 GPU
Unable to determine the device handle for GPU 0000:ca:00.0: Unknown Error

# lspci：设备可能消失，或配置空间读取返回全 0xFF
ca:00.0 3D controller: NVIDIA Corporation Device 2330 (rev ff)
    !!! Unknown header type 7f

还可以查询物理 GPU 清单，与服务器的预期配置对照：

nvidia-smi --query-gpu=index,uuid,pci.bus_id --format=csv

nvidia-smi --list-gpus 的输出可能包含 MIG（Multi-Instance GPU，多实例 GPU）创建的实例或错误消息，因此不能直接用输出行数判断物理 GPU 数量。上面的查询在 GPU 不可达时也可能失败，报错本身同样是排查线索。

应用程序端可能出现 CUDA error: unspecified launch failure、NCCL 的 unhandled cuda error，或者训练任务一直无响应，最终超时。这些报错并非 Xid 79 独有，仍需结合内核日志确认。

3.2 可能的原因

NVIDIA 对 Xid 79 的描述是：驱动尝试通过 PCIe 访问 GPU 时，发现 GPU 已不可达。常见原因是 PCIe 连接的硬件问题导致链路中断，也可能与 GPU 硬件或驱动有关。¹ 结合官方文档和故障案例，排查方向大致分为以下五类。表中的现象是线索，不是单独定性的依据。^{5 6}

3.3 排查步骤

1. 先确定影响范围。 涉及几块 GPU？只出现在这台服务器上，还是同型号设备都有？最近是否更新过驱动、固件或 BIOS？如果同一台服务器上的多块 GPU 同时掉卡，应优先检查共用的供电、主板或 PCIe 组件。
2. 检查内核日志上下文。 Xid 79 前后是否有 PCIe AER 错误、温度告警或 Xid 119/120？先查看前后几十行，必要时扩大时间范围，避免遗漏更早的故障。
3. 确认 PCIe 设备是否仍可访问。 执行 sudo lspci -s 0000:ca:00.0 -vv，将地址替换为实际 GPU 的完整 PCI BDF。rev ff、配置空间全为 0xFF 或设备消失，都提示访问异常，但不能据此断定 GPU 已物理断开。当设备无法访问时，nvidia-smi -r 通常无法完成重置，应准备按平台要求重启或断电后重新启动。
4. 重启前保存证据。 尽可能执行 sudo nvidia-bug-report.sh，收集崩溃转储和诊断日志，再安排恢复操作。⁵ 云端环境应遵循云服务商的处理流程：AWS 对部分反复发生的问题建议停止并启动实例，但这会丢失实例存储（instance store）中的数据，操作前应先保存所需数据，也不能保证每次都会分配到不同宿主机。⁷ Google Cloud 的 Xid 79 指引涉及紧急维护或自动主机维护。需要更换或修复宿主机时，应联系云服务商，不能假设在虚拟机内执行重启就能解决底层硬件问题。^{8 9}
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，并根据诊断结果评估返修或更换。²

四、故障排查案例二：ECC 错误（Xid 48 / 63 / 64 / 92 / 94 / 95）

4.1 背景：什么是 ECC，SBE 与 DBE 有何区别

内存中的位可能受到电气噪声、辐射或硬件缺陷影响而翻转。ECC（Error Correcting Code，纠错码）用于检测和纠正这类错误，广泛用于数据中心 GPU 的显存及其他受保护存储结构；具体保护范围取决于 GPU 架构和配置。

在常见的 ECC 术语中，单比特错误（SBE，通常可纠正）可以由硬件修正；双比特错误（DBE，通常不可纠正）能被检测到，但无法通过对应的纠错机制修复。不同架构可能采用更复杂的保护机制，因此排查时应以驱动报告的“可纠正／不可纠正”类别为准。不可纠正错误可能导致相关应用程序终止，以避免使用不可靠的数据；是否需要立即重置 GPU，则取决于错误隔离结果和驱动给出的恢复操作。¹²

看到 ECC 相关 Xid 后，首先区分：错误是否可纠正，影响是否已被隔离？

4.2 如何理解相关 Xid

ECC 事件可能产生多条相关消息，但下面展示的是它们之间的关系，不是每次都会完整出现、顺序固定的日志流程：

可纠正的单比特 ECC 错误率过高 → Xid 92（状态提示）

不可纠正的 ECC 错误 → 可能报告 Xid 48（Double Bit ECC Error）
   │
   ├─ 错误隔离结果（支持该功能的 Ampere 及更新 GPU）：
   │      Xid 94 = 错误已隔离，受影响的应用程序需要重启
   │               可能伴随进程清理消息 Xid 45
   │      Xid 95 = 错误未能隔离，需要重置 GPU 或重启节点
   │
   ├─ 内存修复记录：
   │      Xid 63 = 成功记录页面退役或行重映射事件
   │      Xid 64 = 页面退役或行重映射记录失败
   │
   └─ 较新驱动可能另报 Xid 154：提示当前所需的恢复操作

行重映射（Row Remapping）是受支持 GPU 的内存修复机制：当某个内存行出现问题时，将其映射到同一内存 bank（存储体）中的备用行。存在待处理的重映射时，通常需要重置 GPU 才能生效，之后对应用程序透明。较早的 GPU 使用页面退役（Page Retirement）来避开有问题的内存页；两者目标相似，机制不同。Xid 63 表示相关事件已成功记录，是否需要立即恢复取决于伴随错误和待处理状态；Xid 64 表示记录失败，需要进一步处理，不能单凭这一条消息就认定 GPU 无法修复。^{12 1}

4.3 使用 nvidia-smi 确认状态

下面是带注释的示意输出，字段会因 GPU 型号和驱动版本不同而变化；N/A 表示该字段不可用，不等于数值为零：

$ nvidia-smi -q -d ECC
    ECC Errors
        Volatile                      ← 当前驱动加载周期内的计数
            SRAM Correctable    : 0
            SRAM Uncorrectable  : 0
            DRAM Correctable    : 0
            DRAM Uncorrectable  : 0   ← 非零时，结合内核日志核对事件
        Aggregate                     ← 持久累计计数；非零不等于当前故障

$ nvidia-smi -q -d ROW_REMAPPER
    Remapped Rows
        Correctable Error           : 0    ← 因可纠正错误而重映射的行数
        Uncorrectable Error         : 0    ← 因不可纠正错误而重映射的行数
        Pending                     : No   ← Yes 表示有重映射等待重置后生效
        Remapping Failure Occurred  : No   ← Yes 需要联系支持并评估返修

Aggregate 计数非零不等于 GPU 已损坏。 它表示持久累计记录，不能直接说明当前任务是否受影响。Volatile 也不能单独用于判定：它通常按驱动加载周期统计，在某些 Linux 配置中，驱动状态释放和重新初始化会影响计数的保留时间。应同时查看两类计数、近期变化趋势和对应日志。¹⁰

可纠正错误产生的重映射通常不意味着需要立即更换 GPU，但也不应一概忽略。 重点关注计数是否持续增长、Pending 是否为 Yes、是否出现重映射失败，以及是否伴随不可纠正错误或任务异常。云平台的操作示例可帮助识别这些字段，实际处理仍应以 GPU 架构和 NVIDIA 当前指引为准。¹³

4.4 决策表：不同消息对应什么操作

下表用于初步判断。如果日志包含 Xid 154 或 nvidia-smi 提供了 GPU Recovery Action，应结合该恢复操作、GPU 型号和平台文档处理；单条消息不能覆盖更严重的伴随错误。

这里存在需要注意的文档差异：当前 Xid Catalog 对 Xid 64 列出的立即操作是重置 GPU，并要求联系支持；GPU Debug Guidelines 对某些 ECC 组合则要求重启节点。该指南对 A100 的 Xid 95 还区分了 MIG 配置：未启用 MIG 时要求立即重启节点；启用 MIG 时，其他未受影响 GPU 实例上的任务可以先完成，再重置整块物理 GPU。应结合实际架构、驱动恢复指示和平台要求执行，不能把某一代 GPU 的处理表直接套用到所有设备。^{3 2}

关于 GPU 重置： sudo nvidia-smi -r -i <index> 可在受支持的平台上重置指定 GPU，而无需重启操作系统。它需要 root 权限，并要求停止占用相关设备的计算、图形和监控进程。NVLink、NVSwitch、Fabric Manager、MIG 和虚拟化配置还可能带来额外限制，部分拓扑需要一起重置相连的 GPU。将 <index> 替换为目标 GPU 当前的索引。重置后应验证 GPU 健康状态，再恢复任务；重置失败或状态仍异常时，可能需要重启或完整断电再启动。云端能否执行该操作，应查阅服务商文档；虚拟机重启不等同于宿主机或物理 GPU 重置。^{10 2 9}

4.5 什么时候需要返修或更换（RMA）

NVIDIA 的 GPU Memory Error Management 文档给出了行重映射相关的 RMA 评估阈值。文档列出的典型触发条件包括：¹⁴

• 同一内存 bank 已因不可纠正错误重映射 8 行，又需要重映射另一行。
• 一个已经重映射过的行再次需要重映射。
• 整块 GPU 因不可纠正错误产生的重映射总数达到 512。

这些条件用于触发或判断重映射失败，不是适用于所有 NVIDIA GPU 的统一换卡标准。Blackwell 还引入了高带宽内存（HBM）通道修复机制：同一 bank 出现第三次相关重映射时可能进入通道修复流程，因此应查阅对应架构的当前策略，不能机械套用上面的数字。¹⁴

是否符合返修条件，应由系统厂商或 NVIDIA 支持结合适用政策和诊断结果确认。NVIDIA Field Diagnostic 是这一流程中的关键诊断工具，通常需要按支持人员指示运行；保留 fieldiag.log、nvidia-bug-report.log.gz 等报告，有助于提交 RMA（Return Merchandise Authorization，返修授权）申请。¹⁵

本文引用的 NVIDIA Tesla 产品 RMA 流程还说明，只在关闭 ECC 时出现的故障不属于其所述受理条件。应结合适用产品和厂商政策理解这一要求，不能将其扩大为所有故障的通用保修结论。对于支持可配置 ECC 的 GPU，生产环境应按工作负载要求和平台建议启用 ECC；不要通过关闭 ECC 来掩盖内存错误。¹⁵

五、梳理排查流程

GPU 故障排查的核心，是结合日志判断问题可能位于应用程序、驱动、平台还是硬件，再选择合适的恢复操作：

1. 从 Xid 和上下文入手。 用 sudo dmesg -T | grep -i xid 查找消息，对照速查表，同时检查前后日志、相关编号和发生顺序。单个 Xid 不能直接给出根因。
2. 遇到掉卡（Xid 79），先检查 PCIe 访问和平台状态。 结合 AER、供电、散热和驱动日志判断，在重启前保存诊断报告；反复发生时隔离组件，并由支持人员指导诊断和返修评估。
3. ECC 错误应结合隔离结果和恢复操作处理。 63/92 单独出现通常无需立即中断任务，但仍需检查状态；94 通常要求重启受影响的应用程序；95、64 或其他不可纠正错误可能需要重置 GPU 或重启节点。Xid 154、GPU 架构和平台指引共同决定具体操作。

需要向系统厂商或云服务商反馈时，NVIDIA 指南建议说明：观察到了什么、何时发生、通过什么方式发现、是否同时影响多台服务器或多块 GPU、发生频率如何，以及近期系统、驱动或应用程序是否有变更。² 同时准备以下资料：

• 操作系统、内核版本、GPU 型号和驱动版本。
• Xid 及上下文，尽可能保存完整的 dmesg 或 journalctl 输出。
• nvidia-smi -q 的输出。
• 已执行的排查步骤及结果。
• sudo nvidia-bug-report.sh 生成的 nvidia-bug-report.log.gz。

附录：数据中心常见 Xid 速查表

NVIDIA 的 Xid Catalog 为 Ampere 及更新架构提供各 Xid 的适用范围和建议操作，包括 IGNORE、RESTART_APP、RESET_GPU、RESTART_BM 和 CONTACT_SUPPORT 等分类。³ 下表结合 GPU Debug Guidelines 和云服务商文档，整理常见编号。操作建议仍需结合伴随错误、驱动恢复指示和具体平台；Volta 及更早架构请同时查阅归档文档。^{2 9 8 16}

几个官方操作分类的含义如下：

• 重启应用程序（RESTART_APP）：恢复或修复受影响的应用程序；仅出现该事件时，通常无需重置 GPU。
• 重置 GPU（RESET_GPU）：在支持的配置上使用 sudo nvidia-smi -r -i <index>，需要 root 权限，并满足设备占用和拓扑限制。
• 重启裸机节点（RESTART_BM）：重启承载 GPU 的物理服务器；在云端需要按服务商流程处理，虚拟机内重启不一定等效。
• 联系支持／运行诊断（CONTACT_SUPPORT / RUN_FIELDDIAG）：联系系统厂商或云服务商，按要求运行 NVIDIA Field Diagnostic；诊断结果用于判断后续修复或 RMA，并不代表看到该分类就必须更换 GPU。

Xid 154 值得单独说明。较新的驱动可能在其他 Xid 之后记录恢复操作的变化，例如：

Xid 154 GPU recovery action changed from 0x0 (None) to 0x2 (Node Reboot Required)

支持该功能的驱动还会在 nvidia-smi -q 的 GPU Recovery Action 字段显示相关状态。可能的恢复操作包括 None（无需恢复操作）、Drain P2P（停止并排空 GPU 间的点对点通信）、Drain and Reset（停止接收新任务，待现有任务结束后重置）、GPU Reset Required（需要重置 GPU）和 Node Reboot Required（需要重启节点）。应结合字段的具体要求和平台文档执行，不能把所有状态都简化成“重置 GPU”。^{1 10}

附录：术语速查

参考资料