NVIDIA Field Diagnostic 完整工作流：GPU 报障与 RMA 前的硬件体检

📌 转载说明：本文首发于微信公众号《闫工的算力工具箱》 原文链接：https://mp.weixin.qq.com/s/ItNdYxG1yEpqKefEkS2VYg

适用机型：A100 / A800（Ampere）、H100 / H800 / H200（Hopper）等数据中心 GPU 配套包：Ampere 包 629-23587-XX86-FLD-38782；Hopper 包 629-24287-XXXX-FLD-41741 本文覆盖：工具选型对比、诊断包获取、skucheck 硬件匹配、驱动卸载、SIT/Level1/Level2 测试、结果判读、日志归档、故障定位

— — —

概述

#

GPU 出现掉卡、算力异常、NVLink 报错等硬件故障，计划走 RMA（Return Merchandise Authorization，退货授权）返厂保修时，NVIDIA 官方受理的第一项材料是 Field Diagnostic 的测试日志。没有这份日志，售后通常无法直接判定故障归属，只能退回要求补测。

Field Diagnostic 是 GPU 硬件级诊断套件，会在裸机状态下对 GPU、NVLink、PCIe、供电线缆、固件版本、显存等做逐项检测，输出结构化结果表与完整日志。它运行时会做硬件级访问，必须先卸载 NVIDIA 内核驱动，否则会直接以 NVIDIA kernel drivers are loaded 报错退出。

本文给出「停服务 → 杀进程 → 卸载内核模块 → 跑测试 → 判读结果 → 归档日志」的完整标准动作，并附实战失败案例的判读方法。

图：GPU 报障返厂的完整链路。Field Diagnostic 日志是提交 RMA 申请的前置材料

— — —

一、原理与背景

#

1.1 三款工具的分工：dcgmi / gpu-burn / fieldiag

#

GPU 检测工具不少，但用途差别很大，拿错工具的结果是白跑几个小时。常被搞混的是下面这三款：

• dcgmi

  是三者中唯一可以在线跑的。dcgmi diag 覆盖 inventory、connectivity、PCIe、NVLink、显存几条线，适合部署前的节点就绪检查，也适合日常巡检时提前发现指标劣化。

• gpu-burn

  用矩阵乘把 GPU 顶到满载，主要暴露散热、供电、显存稳定性问题。输出只有"过 / 不过"和实时温度、功耗读数，适合装机验证和性能基线建立，但定不了位。

• fieldiag

  做的是低层硬件访问：逐项检查 NVLink 物理链路、PCIe 速率与宽度、供电线缆承载能力、固件版本一致性，并输出结构化结果表与可归档日志。

三者中只有 fieldiag 的结果被 NVIDIA 售后承认为 RMA 依据，所以报障返厂这一步绕不开它。另外两款即便跑出异常，也只是"怀疑硬件故障"的旁证，售后依然会要求补跑 fieldiag。

📌 简记：日常巡检看 dcgmi，装机烤机用 gpu-burn，报障返厂走 fieldiag。

1.2 skucheck：为什么必须匹配硬件配置文件

#

fieldiag 测试序列的第一项是 skucheck，SIT、Level 1、Level 2 都会跑，耗时约 15 分钟。它不做压力，做的是核对：拿一份预期硬件清单，和服务器上实际读到的硬件逐项比对。

这份预期清单就是 SKU 配置文件，以 JSON 格式随诊断包分发，描述的是这台机器"应该长什么样"：

skucheck 要求逐项完全一致，型号或板卡名称对不上就直接报错：

Either board name/Gpu model mismatch

此后测试序列不再继续，整轮以 FAIL 收场。实测中出现过一次典型情况：同一个诊断包，用厂商提供的 Live 环境启动能正常跑完，把目录整个拷贝到自建系统上运行却在 skucheck 卡住。原因是两边的配置文件不同——厂商在做 Live 环境时已经把 JSON 替换成与自家硬件匹配的版本，而拷贝出来的是通用配置，与实际板卡对不上。

处理方式上，向服务器厂商索取与本机型匹配的诊断包，不要拿 A 厂商的包去测 B 厂商的机器。如果确认只有厂商 Live 环境能跑通，说明匹配的配置文件在镜像里，稳妥做法是继续用厂商提供的完整环境，而不是单独把目录拷出来用。

⚠️ skucheck 报板卡不匹配时，先别急着怀疑 GPU 坏了。这一步失败通常说明配置文件不对，跟硬件好坏没关系。配置用错了，好机器一样过不去。

1.3 为什么必须先卸驱动

#

Field Diagnostic 需要通过 PCIe 直接访问 GPU 硬件寄存器与 NVLink 链路，做低层级的连通性与压力测试。NVIDIA 内核驱动（nvidia、nvidia_uvm、nvidia_drm 等）一旦加载，会接管这些硬件资源，诊断程序拿不到独占访问权。

测试的前置条件就三条：驱动完全卸载、没有进程占用 /dev/nvidia*、Fabric Manager 服务已停止。缺任何一条，诊断都会拒绝启动，或者给出不完整的结果。

跑之前用这三条命令过一遍，全过才继续：

lsmod | grep nvidia                        # 应无输出
lsof /dev/nvidia* 2>/dev/null              # 应无输出
systemctl status nvidia-fabricmanager      # 应为 inactive

1.4 测试级别与耗时

#

推荐顺序是先跑一遍 SIT，通过后再上 Level 1；只有需要完整覆盖、或者售后明确要求的场景，才跑 Level 2。

1.5 结果会保留三种状态

#

日志文件 logs_<时间戳>.tgz 在 PASS / FAIL / RETEST 三种结果下都会生成，不是只有失败才产出。归档时不要只看结果挑日志。

— — —

二、规划与准备

#

2.1 获取测试包

#

fieldiag 不是公开下载的软件。NVIDIA 对它的分发对象有范围限制，获取渠道主要有三条：

⚠️ DGX Spark 那条渠道最容易踩坑：它是 ARM64 平台的一体机专用包，装在普通 x86 服务器上没有对应的诊断二进制，跑不起来。HGX 8 卡模组仍然走前两条渠道。

包名有固定格式：629-<包号>-<平台标识>-ALL.tgz。本文用到的两个：

两个包都自带 fieldiag.sh 主脚本与配套的 SKU 配置文件，解压即用，不需要额外安装依赖（ipmitool 仅在做 BMC 检查时用到，加 --no_bmc 可跳过）。

拿到包后先确认两件事：包的代际和板卡型号跟本机型对不对得上，包内有没有带 SKU 配置文件。这两项不对，跑起来就会卡在 skucheck。

2.2 停止占用 GPU 的服务

#

# 停止 Fabric Manager（最关键）
systemctl stop nvidia-fabricmanager
# 部分环境服务名为 nv-fabricmanager
systemctl stop nv-fabricmanager
# 停止其他可能占用的服务
systemctl stop nvidia-persistenced 2>/dev/null
systemctl stop dcgm 2>/dev/null
systemctl stop gdm 2>/dev/null
systemctl stop lightdm 2>/dev/null
systemctl stop sddm 2>/dev/null

📌 桌面环境服务（gdm / lightdm / sddm）在服务器上通常不存在，命令报错可忽略；容器化节点与无头节点也不会启用这些服务。

2.3 清理残留进程

#

# 查看占用情况
lsof /dev/nvidia* 2>/dev/null
fuser -v /dev/nvidia* 2>/dev/null
# 强制清理
kill -9 $(lsof -t /dev/nvidia* 2>/dev/null) 2>/dev/null
pkill -9 -f nv-fabric 2>/dev/null
pkill -9 -f fabricmanager 2>/dev/null

2.4 按依赖顺序卸载内核模块

#

卸载顺序不能颠倒。上层模块依赖下层，顺序错了会报 Module is in use。

modprobe -r nvidia_uvm
modprobe -r nvidia_drm
modprobe -r nvidia_modeset
modprobe -r nvidia_peermem
modprobe -r nvidia
# 确认卸载干净（应无任何输出）
lsmod | grep nvidia

若仍有残留，可强制卸载：

rmmod -f nvidia_uvm nvidia_drm nvidia_modeset nvidia_peermem nvidia 2>/dev/null

— — —

三、实施步骤

#

3.1 一键卸载脚本

#

将以下脚本保存为 /root/unload_nvidia_for_fieldiag.sh，Ampere 与 Hopper 两个包通用：

cat > /root/unload_nvidia_for_fieldiag.sh << 'EOF'
#!/bin/bash
echo "=============================================="
echo "  Fieldiag 驱动卸载脚本"
echo "=============================================="
# 1. 停止相关服务
echo "[1/5] 停止相关服务..."
systemctl stop nvidia-fabricmanager 2>/dev/null || systemctl stop nv-fabricmanager 2>/dev/null
systemctl stop nvidia-persistenced 2>/dev/null
systemctl stop dcgm 2>/dev/null
systemctl stop gdm 2>/dev/null
systemctl stop lightdm 2>/dev/null
systemctl stop sddm 2>/dev/null
# 2. 杀掉占用 GPU 的进程
echo "[2/5] 杀掉占用 GPU 的进程..."
PIDS=$(lsof -t /dev/nvidia* 2>/dev/null)
if [ -n "$PIDS" ]; then
    echo "发现占用进程: $PIDS"
    kill -9 $PIDS 2>/dev/null
    sleep 1
fi
pkill -9 -f nv-fabric 2>/dev/null
pkill -9 -f fabricmanager 2>/dev/null
# 3. 按依赖顺序卸载模块
echo "[3/5] 卸载 NVIDIA 内核模块..."
modprobe -r nvidia_uvm 2>/dev/null
modprobe -r nvidia_drm 2>/dev/null
modprobe -r nvidia_modeset 2>/dev/null
modprobe -r nvidia_peermem 2>/dev/null
modprobe -r nvidia 2>/dev/null
rmmod -f nvidia_uvm nvidia_drm nvidia_modeset nvidia_peermem nvidia 2>/dev/null
# 4. 检查结果
echo "[4/5] 检查卸载结果..."
if lsmod | grep -q nvidia; then
    echo "【失败】仍有 NVIDIA 模块未卸载干净："
    lsmod | grep nvidia
    echo "请排查：lsof /dev/nvidia* 与 fuser -v /dev/nvidia*"
    exit 1
else
    echo "【成功】NVIDIA 驱动已全部卸载干净"
fi
# 5. 最终确认
echo "[5/5] 最终确认..."
lsmod | grep -E 'nvidia|nouveau' || echo "无"
echo "=============================================="
echo "  可以开始运行 Fieldiag 了"
echo "=============================================="
EOF
chmod +x /root/unload_nvidia_for_fieldiag.sh

执行：

/root/unload_nvidia_for_fieldiag.sh
# 看到「【成功】NVIDIA 驱动已全部卸载干净」才继续

3.2 Ampere 包（A100 / A800）

#

⚠️ Ampere 包不支持 --gpufielddiag 和 --ist，这两个是 Hopper 包才有的参数。如果 ./fieldiag.sh --help 里只列出 --sit / --level1 / --level2 / --test 四种模式，说明手上这个就是 Ampere 包，此时报"参数不认识"是正常的，不是包坏了。

# 1. 卸载驱动
/root/unload_nvidia_for_fieldiag.sh

# 2. 快速检查
cd ~/fieldiag/629-23587-XX86-FLD-38782
./fieldiag.sh --sit --no_bmc

# 3. 通过后再跑 Level 1
./fieldiag.sh --level1 --no_bmc

# 4. 需要最完整覆盖时跑 Level 2
./fieldiag.sh --level2 --no_bmc

3.3 Hopper 包（H100 / H800 / H200）

#

# 1. 先尝试直接运行（Hopper 包对驱动处理较友好）
cd /var/diags/629-24287-XXXX-FLD-41741
./fieldiag.sh --sit --no_bmc

# 2. 若报驱动问题，再用通用的卸载脚本
/root/unload_nvidia_for_fieldiag.sh
./fieldiag.sh --sit --no_bmc

# 3. Level 1
./fieldiag.sh --level1 --no_bmc

# 4. Level 2（最完整）
./fieldiag.sh --level2 --no_bmc

# 5. 可选：单独跑 GPU Field Diag
./fieldiag.sh --gpufielddiag --no_bmc

📌 Hopper 包的默认行为是所有测试跑完再汇总，即使中间某项已失败也会继续。如需"遇到第一个错误立即停止"，加 --fail_on_first_error。

3.4 测试完成后操作

#

# 保存日志（日志在当前目录）
ls -l logs_*.tgz
cp logs_*.tgz /path/to/safe/dir/
# 恢复服务（重启最干净）
reboot

— — —

四、验证与结果判读

#

4.1 三种结果的含义

#

RETEST 怎么处理：它跟 FAIL 是两回事，RETEST 表示测试环境没准备好，测试根本没真正跑起来，所以日志里也找不到硬件故障的证据。最常见的原因是驱动没卸干净，其次是端口被其他进程占用。

处理顺序：先跑一遍 3.1 的卸载脚本，用 1.3 的三条自检命令确认全过，再重跑测试。如果自检也过了仍然 RETEST，再去看日志里的 pre-check 提示，那里会写明具体卡在哪一项。

4.2 失败结果表怎么读

#

测试结束后屏幕输出一张分阶段表格，重点看表头三处状态（如 Dumping inforom OK / Testing skucheck OK / Testing connectivity FAILED）。表格各列含义：

图：实战失败案例。前两项通过、第三项 connectivity 失败并报 PCI Express bus error，最终判定 FAIL

4.3 定位故障 GPU 的三步

#

1. 先看 Subtest 列的失败项：nvlink 失败说明 NVLink 链路异常；powercable 失败查电源线缆；check_gpu_config 失败查固件与驱动版本。
2. Component Id 对应到具体 GPU 的物理位置，结合 HGX baseboard 拓扑判断是哪一张卡。
3. 最后解包日志看详情：

tar xzf logs_<时间戳>.tgz -C /tmp/fieldiag_logs
cd /tmp/fieldiag_logs
ls
# fieldiag.log   — 主测试日志
# <host>_*.log   — 各子测试详细输出
grep -A 20 "000000000143" fieldiag.log | head -50

报错按严重程度分三类：

💡 走 RMA 时，logs_*.tgz 里的 fieldiag.log 是必交资料，连同 nvidia-bug-report.log.gz 一起提交到官方 RMA 门户。

— — —

五、常见问题与排错

#

5.1 现象速查

#

5.2 关于 Unknown FRU header version 0x20 警告

#

启动时前若干行刷红色 Unknown FRU header version 0x20 属正常现象，不必紧张。

原因是系统检测到部分 FRU（Field Replaceable Unit，现场可更换单元）信息版本不匹配，常见于不同主板 / BMC 之间 FRU 格式差异，或者旧版诊断工具识别不了新主板的 FRU 数据。

图：启动前若干行刷红色 FRU 警告属正常现象；关键是下方随后出现 PASS: NVIDIA kernel drivers unloaded

警告本身不影响测试结果，真正要看的是接下来的日志：

INFO: Verifying if NVIDIA kernel drivers are unloaded
PASS: NVIDIA kernel drivers unloaded        ← 关键，看到这个才算驱动真卸干净
Unpacking...
HGX-N FIELD DIAGNOSTIC

若在 FRU 警告之后仍出现 PASS: NVIDIA kernel drivers unloaded，则一切正常。只有当警告之后直接报错退出（如 FRU read failed）时，才需要检查 BMC 固件版本或更换新版诊断包。

— — —

六、安全与规范

#

1. 测试会中断该节点所有 GPU 业务，须在维护窗口执行，并确认业务已迁移。
2. 驱动卸载与重启属高风险操作，动手前记录当前驱动版本与服务状态，便于恢复。
3. 卸载后节点处于无驱动状态，不可执行任何 GPU 业务，测试完成立即 reboot 恢复。
4. 日志按节点与时间归档。logs_<时间戳>.tgz 的命名里带时间，归档时保留原始文件名，避免与其他节点混淆。
5. RMA 材料要一次交齐，fieldiag.log 与 nvidia-bug-report.log.gz 一并提交，缺项会被退回补测。
6. 自定义 OS 环境要先清理后台干扰，确认没有其他进程或服务影响诊断运行。

— — —

参考

#

• NVIDIA 企业支持门户（开支持单、查询 RMA 入口）：https://support.nvidia.com/
• NVIDIA Field Diagnostic 官方文档（SKU 配置、命令行参数、结果码与日志命名规则）：https://docs.nvidia.com/deploy/hw-field-diag/index.html
• NVIDIA DGX Spark Field Diagnostics（含 Spec JSON 文件与日志路径说明）：https://nvidia.custhelp.com/app/answers/detail/a_id/5767/~/nvidia-dgx-spark-field-diagnostics
• NVIDIA DCGM（Data Center GPU Manager）项目主页：https://github.com/NVIDIA/dcgm
• gpu-burn 项目主页（多卡 CUDA 压力测试）：https://github.com/wilicc/gpu-burn
• 随诊断包分发的 PDF 文档：Quick Start Guide DU-05711-001、Software Guide DU-05363-001
• 同系列：《NVIDIA Tesla GPU RMA（退货授权）流程指南》

📖 推荐阅读

利旧 400G AOC / MPO 线缆复用前的 4 小时压力测试：PRBS-31Q 双向验收与判定标准

8卡变7卡、93°C还在Throttling：什么原因

ESXi系统盘重装后虚拟机消失？别慌，三步救回数据盘里的虚拟机

GPU全在、驱动正常，训练就是卡死——NVLink悄悄坏了一半