GPU 服务器故障诊断手册：XID 错误码、ECC 与换件决策
一句话：GPU 报错时，绝大多数人做的第一件事是重启；正确做法是先把 XID 分成"应用错、驱动错、硬件错"三类，再决定是重启、排空、换件还是报修。判错的代价是双向的——把应用 bug 当硬件换掉一张卡，和把退化中的 HBM 当成软件问题反复重启，都很贵。
本文只讲一件事：从报错现象走到可执行结论。所有结论都能落到三句话之一——重启该应用、重置该 GPU、发起 RMA。
一、XID 是什么：驱动写给内核的判据，不是硬件判决书
XID 是 NVIDIA 驱动在检测到 GPU 异常后写入内核日志（/var/log/messages 或 syslog）的错误报告，格式固定：
NVRM: GPU at 0000:03:00: GPU-b850f46d-d5ea-c752-ddf3-c4453e44d3f7
NVRM: Xid (0000:03:00): 48, pid=7062, ...前一行的 GUID 与 PCI 地址把后面所有 Xid 归到同一张卡，这是排查的入口：先按 PCI 地址聚合，再看同一张卡上的 Xid 序列。
NVIDIA 自己的定义很克制：Xid 消息"最常由驱动错误地编程 GPU，或发送给 GPU 的命令被破坏引起"，可能指向硬件、NVIDIA 软件或用户应用三类问题。换句话说，XID 编号是分类起点，不是结论。同一张卡上 FB（frame buffer）或 PCIe 的数据损坏，理论上能伪造出几乎任何一条 Xid。
所以判读必须先分流，再落结论。
二、第一步：三个问题快速分流
拿到报警别急着重启，先回答三个问题：
| 问题 | 判读含义 |
|---|---|
| 只有这一个进程崩，还是同卡所有进程都崩？ | 只崩一个 → 优先怀疑应用；同卡全崩 → 驱动或硬件 |
| 是复现型（同样作业必现），还是随机型（换作业也偶发）？ | 复现型 → 应用或特定 kernel；随机型 → 硬件或链路 |
| 换一张卡跑同样作业是否消失？ | 消失 → 硬件定位成功；迁移后复现 → 应用或框架 |
三个问题问完，90% 的工单已经能定性。剩下的 10% 才是真正需要读错误码的部分。
三、高频 XID 分组判读
下表只收录机房现场真正常见的一批，按"根因归属"分组，比按编号顺序背更有效。
3.1 应用类：先怀疑代码，别动硬件
| XID | 官方含义 | 判读要点 |
|---|---|---|
| 13 | Graphics Engine Exception | 典型是越界访问（走出数组末尾），也可能是非法指令、非法寄存器。用 Compute Sanitizer memcheck 或 CUDA-GDB 能直接指出出问题的那行代码 |
| 31 | GPU memory page fault（FIFO: MMU Error） | MMU 报非法地址访问，绝大多数是应用层 bug，少数是驱动或硬件 |
| 43 | Reset Channel Verif Error | 应用触发软件故障被终止，GPU 本身仍健康，官方明确"通常不是驱动 bug，而是用户应用错误" |
| 45 | Preemptive Channel Removal | 应用被 Ctrl-C、kill 或 GPU 复位拆掉时的伴随信息，通常无需动作。A100 上若单独出现，要查 Fabric Manager 是否与 GPU 同机运行并异常退出 |
这一组的关键判断是"GPU 是否仍健康"。43 和 45 明确不算硬件问题；13 和 31 要先用工具证明是应用错——证明不了，才进硬件流程。
3.2 显存类：XID 48 / 63 / 64 / 92 / 94 / 95 / 140
这是最容易误判、也最需要看数字的一族。判读依赖三个前提概念：
- SBE（single-bit error）：单比特错，ECC 可纠正，不致命，但位置重复出现会触发页退役或行重映射；
- DBE（double-bit error）：双比特错，不可纠正，
Xid 48就是它； - contained / uncontained：A100 起引入错误隔离，把不可纠正错误限制在出错的那个应用内（94），还是影响整卡所有应用（95）。
| XID | 含义 | 该做什么 |
|---|---|---|
| 48 | Double Bit ECC Error | 若后面跟着 63 或 64：排空节点、等作业结束、重置 GPU。若没有跟 63/64：跑现场诊断收集更多信息，并按阈值评估是否 RMA |
| 63 | 行重映射/页退役记录成功 | 若与 48 同时出现 → 排空、重置；若单独出现（来自 SBE）→ 可继续跑，等到方便时重启 |
| 64 | 行重映射/页退役记录失败 | 记录失败是硬信号：A100 起立即重启节点；legacy 卡立即重置该 GPU。持续出现则排空、报修 |
| 92 | High single-bit ECC error rate | 单比特错误率过高，跑现场诊断，按错误率趋势与阈值决定是否 RMA |
| 94 | Contained ECC error | 只需重启出错的那个应用，其他应用不受影响；方便时再重置 GPU 让重映射生效 |
| 95 | Uncontained ECC error | 不可纠正且未被隔离：MIG 开着就先排空其他实例再重置；MIG 关着则立即重启节点 |
| 140 | ECC Unrecovered Error | 驱动连"把页标记为不可用 / 重映射"都做不到了。重置 GPU，仍复现就联系厂商 |
| 171 / 172 | 48 的细化：DRAM 错 / SRAM 错 | 决定后续走显存 RMA 还是 SRAM RMA，判据不同（见第五节） |
一句话记住优先级：94 只坑自己，95 坑全卡，64 是记录失败必须马上动，140 是连补救都失败。
3.3 链路与总线类：74 / 79 / 32 / 110
| XID | 含义 | 判读要点 |
|---|---|---|
| 74 | NVLink Error | 链路本身故障，也可能是对端设备故障导致这条链路掉了——一张卡坏了，和它相连的卡也会报 74。必须用 DWORD 解码（见第四节） |
| 79 | GPU has fallen off the bus | 驱动通过 PCIe 访问 GPU 时发现设备不见了。常见原因是 PCIe 链路硬件故障导致链路 down。先查系统事件日志与内核 PCIe 事件，再排空报修 |
| 32 | PBDMA Error | 驱动与 GPU 之间经 PCIe 的通信流由 DMA 控制器管理，报错主要涉及 PCI 链路质量问题，官方明确指出"一般不是用户应用引起的" |
| 110 | Security fault error | 除非硬件故障，否则不该出现。先回退最近的硬件改动并冷启动，不行就联系厂商 |
这组里 74 和 79 是最需要现场纪律的：79 一旦出现，这张卡基本进入换件流程；74 则要先把对端一起查，否则容易换错卡。
3.4 平台类：61 / 62 / 119 / 120 / 121
| XID | 含义 | 动作 |
|---|---|---|
| 61 | PMU Breakpoint | 上报问题并重置 GPU |
| 62 | PMU Halt（微控制器停机） | 上报问题并重置 GPU |
| 119 / 120 | GSP RPC Timeout / GSP Error | 先重置 GPU，不行则整机断电冷启；冷启后仍复现，按 GPU 调试指南继续收集 |
| 121 | C2C Link corrected error（Grace 平台） | 已由系统纠正，无运行影响；在维护窗口重置 GPU 重新训练链路即可 |
61/62/119/120 共同特征是"GPU 内部协处理器失联"，软件侧能做的只有重置与冷启，重复出现即为硬件信号。
四、XID 74 的 DWORD 位解码：判断 NVLink 该不该换件
Xid 74 的日志尾部带一串十六进制 DWORD，形如 (0x12345678, ...)。取第一个 DWORD（加粗那个），从最低位（LSB）开始数位：
| 置位 | 含义 | 现场动作 |
|---|---|---|
| bit 4 或 bit 5 | 很可能是 ECC/Parity 的硬件问题 | 同一链路出现 2 次以上即报修 |
| bit 21 或 bit 22 | 通道信号完整性（SI）临界 | 先查机械连接、重插线缆/重上板 |
| bit 8、9、12、16、17、24、28 | 可能是硬件问题 | 检查机械连接并重插；仍复现则跑诊断 |
这套位判读的价值在于：它能区分"该重插"和"该换件"。不分位、只看"74 出现几次"，运维会陷入反复重插的循环。
配合 nvidia-smi nvlink -e 看每条链路的 CRC/replay 计数，能进一步确认是持续性退化还是单次事件。
五、ECC 阈值：什么时候真的该换卡
这一节是本文最该被收藏的部分，因为"该不该换"不该靠感觉。
5.1 行重映射的三条失败判据（A100 / H100 起）
行重映射把退化单元换成 HBM 里的备用行，全卡最多 512 次重映射。出现以下任一情况即置位 row-remapping failure flag：
- 某个 bank 已重映射 8 行不可纠正错误，还要再映射第 9 行；
- 对已经重映射过的行再次尝试映射（这可能发生在同一 bank 内远少于 8 次的时候）；
- 不可纠正错误的重映射累计达到 512 次。
失败标志置位、并经现场诊断工具（Field Diagnostic）验证后，即满足 RMA 条件。
5.2 SRAM（L2）的 RMA 判据
SRAM 结构靠 ECC 或 parity 保护，密度高，本底辐射造成的偶发不可纠正错属正常现象，单次不能作为换件依据。判据按保护方式分：
- parity 保护的 SRAM：同一地址 bank 内 UCE 唯一计数 > 4；
- SECDED ECC 保护的 SRAM：同一地址 bank 内 UCE 唯一计数 > 2。
5.3 页退役（Volta 及更早一代）的判据
老卡走动态页退役，全卡上限 64 页（每页 64 KiB）：
- 60 页即具备 RMA 资格；
- 64 页会在 Field Diagnostic 中直接判失败；
- 特例：已退役 15 页以上，且仍以每周 ≥1 页的速度新增时，可以在未到 60 页前申请评估。
5.4 读数字的三个命令
# 显存错误与行重映射状态（看 Remapped Rows / Pending / Failure）
nvidia-smi -q -d ECC,PAGE_RETIREMENT,ROW_REMAPPER
# 单卡精简版：只看是否 pending / failure
nvidia-smi --query-gpu=index,pci.bus_id,ecc.errors.uncorrected.volatile.total,retired_pages.pending,remapped_rows.pending,remapped_rows.failure --format=csv关键区别要记牢：remapped_rows 记录的是写入 InfoROM 的条目数，不是硬件里已经完成的映射数；映射要等 GPU 重置才真正生效。所以看到 pending 不等于已经修好，看到计数不为 0 也不等于已经坏透。
六、换件判定矩阵
把前面的判据压成一张可以贴在工位上的表：
| 证据组合 | 结论 | 动作 |
|---|---|---|
| 仅 13/31，且 memcheck 能定位到具体代码行 | 应用 bug | 交给用户改代码；不动硬件 |
| 43/45 单独出现，GPU 健康检查通过 | 应用终止的正常伴随信息 | 记录后关闭工单 |
| 48 →（63 或 64） | 发生不可纠正显存错，且已记录 | 排空、等作业结束、重置 GPU；继续观察 |
| 64 反复出现（记录失败） | InfoROM 写入侧失效 | 立即重启/重置；持续则 RMA |
| 94 | 隔离成功 | 只重启该应用；维护窗口重置 |
| 95 | 隔离失败 | 立即排空并重启节点；记录 RMA 证据 |
| 140 | 连重映射都失败 | 重置；复现即 RMA |
| row-remapping failure flag = true（8 行/重复行/512 次） | 达到显存 RMA 判据 | 跑 Field Diagnostic，发起 RMA |
| SRAM UCE 超阈值（parity > 4 或 SECDED > 2） | 达到 SRAM RMA 判据 | 同上 |
| 74 且第一个 DWORD bit4/5 置位、同链路 ≥2 次 | NVLink 硬件退化 | 报修，勿反复重插 |
| 74 且 bit21/22 置位 | 信号完整性临界 | 检查机械连接、重插 |
| 79 | GPU 掉总线 | 排空 + 收集 PCIe AER 日志 + RMA |
| 92 且单比特错误率持续上升 | HBM 退化趋势 | 现场诊断 + 按趋势申请评估 |
| 61/62/119/120 重置后反复 | 协处理器故障 | 冷启一次；仍复现则 RMA |
| 121（Grace C2C） | 已纠正，无影响 | 维护窗口重置链路 |
七、证据采集：一次抓全，别让厂商来回要日志
报修被退回最常见的原因是证据不全。下面这段可以一次跑完并打包：
#!/usr/bin/env bash
OUT=/tmp/gpu-evidence-$(hostname)-$(date +%F-%H%M)
mkdir -p "$OUT"
# 1. XID 时序（按卡聚合，先看序列再看单条）
grep -h "NVRM: Xid" /var/log/messages* 2>/dev/null | tail -n 200 > "$OUT/xid.log"
grep -h "NVRM: GPU at" /var/log/messages* 2>/dev/null | tail -n 50 > "$OUT/gpu-map.log"
# 2. 显存与重映射状态
nvidia-smi -q -d ECC,PAGE_RETIREMENT,ROW_REMAPPER > "$OUT/ecc-rowremap.txt"
nvidia-smi -q > "$OUT/nvidia-smi-full.txt"
nvidia-smi -q -d TEMPERATURE,POWER,CLOCK,PERFORMANCE > "$OUT/thermal-power.txt"
# 3. PCIe 链路与 AER（掉总线/降速的关键证据）
lspci -vvv 2>/dev/null | grep -A3 -i "nvidia\|3d controller" > "$OUT/lspci.txt"
dmesg | grep -iE "pcie|aer|link.*down|corrected|fatal" | tail -n 200 > "$OUT/pcie-aer.log"
# 4. NVLink 计数
nvidia-smi nvlink -s > "$OUT/nvlink-status.txt" 2>/dev/null
nvidia-smi nvlink -e > "$OUT/nvlink-errors.txt" 2>/dev/null
nvidia-smi nvlink -c > "$OUT/nvlink-capabilities.txt" 2>/dev/null
# 5. 主动诊断（短测，几秒到一分钟）
dcgmi diag -r 1 > "$OUT/dcgm-diag-short.txt" 2>&1
# 6. 官方打包（含内核日志与驱动内部状态）
nvidia-bug-report.sh --output-file "$OUT/nvidia-bug-report.log.gz"
tar czf "$OUT.tar.gz" -C /tmp "$(basename $OUT)"
echo "collected: $OUT.tar.gz"采集纪律三条：
- 先存证，再重置。重置会清掉 volatile 计数，先抓日志；
- 带上时序。单条 Xid 没有意义，
tail -n 200里的先后顺序才有； - 短测用 -r 1，长测用 -r 3。
dcgmi diag -r 1几秒到一分钟适合做作业前预检；-r 3约 30 分钟，用于送修前完整验证。
八、换件后的复验：不做这一步，等于没修
换卡/换线/换交换机端口之后，必须留下"修好了"的证据，否则同类问题下次会以另一种形态回来。
- 节点健康：
dcgmi diag -r 2全绿，XID 清零； - 显存干净：
nvidia-smi -q -d ECC,ROW_REMAPPER中 DBE/volatile 归零、pending 为 false； - 链路速率达标：
nvidia-smi nvlink -s显示每链路预期速率（Hopper 400 GB/s 级），PCIe 侧lspci -vvv的 LnkSta 为预期宽度与速率（如 x16 / 32GT/s），不是降级后的 x8； - 集合通信回到基线：用现有 NCCL 基线（如
all_reduce_perfbusbw）对比换件前后，差值应在噪声范围内； - 记录归档：卡 SN、槽位、XID 序列、复验数据一并入库，这是下次 20 秒定位同类问题的资产。
九、三个高频误判
- 把 43/45 当硬件故障。它们明确是"应用被终止"的伴随信息，尤其 45 在 A100 上还可能只是 Fabric Manager 同机异常退出。按硬件换件，等于白换。
- 把 94 当 95。94 只需重启应用，95 要重启节点。判反了，要么造成不必要的整机重启，要么让污染扩散到全卡作业。
- 只看 XID 不看对端。74 的一多半误换件来自"没查对端"。一张 GPU 掉链路，和它相连的 GPU 与 NVSwitch 都会报错，谁是真凶要靠 DWORD 位和
nvlink -e计数判断。
收口三句
- 先分流，再读码：三个问题（范围、复现性、换卡是否消失）就问掉了大部分工单；
- 显存看数字，链路看位：ECC 靠行重映射/页退役阈值下结论，NVLink 靠 DWORD 位区分重插与换件；
- 先存证再重置：证据集不全的报修，一定会被退回来重跑一遍。