掉卡排查实录：RTX 5070 反复 Xid 79，如何排查建立证据链

掉卡排查实录：RTX 5070 反复 Xid 79，如何排查建立证据链

Deng YongJie's blog 2 2026-10-03

掉卡排查实录：RTX 5070 反复 Xid 79，如何排查建立证据链

大模型推理基础设施实战系列 · 第 8 篇

系列前七篇讲的是怎么把 GPU 用满；接下来三篇讲 GPU"没了"的时候怎么办：两张不同档位显卡的 Xid 79 掉总线（本篇与下一篇），以及一次被误当成 NCCL 网络故障的 NVSwitch 物理链路问题（第 10 篇）。三篇的共同主题是证据纪律——每条线索只说它能证明的话。

1. 背景与问题：一张反复"掉总线"的 RTX 5070

故障对象是一台8卡算力服务器：

项目 记录
GPU GeForce RTX 5070（GB205，PCI ID 10de:2f04），PCI 地址 0000:01:00.0
系统 / 内核 Ubuntu 22.04.5 LTS；5.15.0-198-generic
采证时已加载驱动 NVIDIA Open Kernel Module 595.99.02（已加载模块、磁盘模块、实际 NVML 库三者一致）
VBIOS 98.05.4a.00.5c
故障表现 nvidia-smi 返回 Unknown Error / No devices were found；内核记录 Xid 79 + Xid 154（Node Reboot Required）
历史 重启可临时恢复，随后复现；完整故障包内可区分四次掉卡事件，横跨 590.44.01 与 595.99.02 两版驱动

2. 先给排查排序，再说依据

这次故障的关键组合是：反复 Xid 79、GPU 和同卡音频功能的 PCIe 配置读取异常、管理接口无法取得设备句柄，且新旧两版驱动下都有记录。

我们的排查优先级：

  1. 优先检查 PCIe 连接、供电路径和显卡本体——插槽接触、转接板/延长线（如实际使用）、显卡供电连接器、PSU 及板载供电。现有证据最值得先沿这条路径走；
  2. 并行核查驱动安装、GSP/VBIOS 与主板固件组合——当前版本有社区同类报告，软件触发设备失联的可能性仍在；
  3. 应用代码/显存不足暂不列为主要解释——直接证据是设备失联，没有证据把故障归因于某个模型、CUDA 算子或普通 OOM。

两点必须说死：这是依据本机证据作出的工程排查排序，不是统计概率——没有换卡、换槽、换供电或严格驱动对照结果，就不能给出"90% 是线""已确认驱动有 bug"之类的结论。这里的"链路"指 CPU/主板到 GPU 的 PCIe 访问路径和供电路径；网线、SSH 连接和显示线不应成为这组证据下的首要怀疑对象。

3. 现场三层证据：都指向"设备不可访问"，也都到此为止

现场三层证据

lspci 仍显示 “NVIDIA RTX 5070”，不代表显卡此刻能正常响应——设备名可能来自系统已枚举的信息。要看配置读取结果：

0000:01:00.0 ... GB205 [GeForce RTX 5070] [10de:2f04] (rev ff) (prog-if ff)
    !!! Unknown header type 7f
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

GPU 和同卡音频功能（0000:01:00.1）的配置空间都读回连续 ff。这说明问题已涉及设备访问层整体，超出任何单个 CUDA 应用的范围；但它仍不能单独区分"物理连接断开"与"设备因硬件/固件/驱动异常不再响应"。

内核侧，当前 595 驱动下两次事件的原始记录（省略主机名，均可对应原始日志行号）：

Oct 14 12:11:50  NVRM: Xid (PCI:0000:01:00): 79, GPU has fallen off the bus.
Oct 14 12:11:50  NVRM: Xid (PCI:0000:01:00): 154, GPU recovery action changed from 0x0 (None) to 0x2 (Node Reboot Required)

Oct 14 23:17:33  NVRM: Xid (PCI:0000:01:00): 79, GPU has fallen off the bus.
Oct 14 23:17:33  NVRM: Xid (PCI:0000:01:00): 154, GPU recovery action changed from 0x0 (None) to 0x2 (Node Reboot Required)

两个 Xid 的语义边界（依据 NVIDIA Xid Catalog）：

  • Xid 79：驱动经 PCIe 无法访问 GPU。常见于链路硬件问题，也可能涉及显卡本体或驱动问题——它本身不能唯一确定故障点；
  • Xid 154：恢复动作变更通知（本次从 None 变为 Node Reboot Required）。它不是另一种根因，也不等于"已经执行了重启"。

硬件快照里还有两条容易被过度解读的线索，先立好边界：

  • 上游桥（0000:00:01.1）的 DevSta: CorrErr+——采集快照存在已纠正错误状态位，但状态位没有精确发生时间，不能单独认定与本次掉卡有因果关系；
  • 上游链路采集时为 2.5GT/s x16（能力 32GT/s）——记录的只是采集时刻的链路状态，空闲降速或异常后状态不能单独证明线材不达标；
  • 另外，GPU 电源策略 on、runtime 状态 active 说明采集时并非 runtime suspended，但这不是电压/电流测量，不能排除供电瞬态。

4. 四次事件、两版驱动、同一张卡

完整故障包（nvidia-bug-report.log，1.48 GB）里，按时间、GPU UUID 与日志来源去重后，可区分四个故障时刻：

四次事件时间线

日志显示时刻 对应启动的已加载驱动 说明
Oct 13 12:26:40 590.44.01 旧版驱动阶段已有故障
Oct 14 10:14:08 590.44.01 同一 GPU 再次故障
Oct 14 12:11:50 595.99.02 当前版本第一次重点事件
Oct 14 23:17:33 595.99.02 当前版本第二次重点事件

四个时刻附近记录的 GPU UUID 相同（脱敏），即同一张卡。三条口径纪律：

  • 同一事件会被收进 kern.log、journalctl、dmesg 多个章节，必须去重——不能把不同章节的重复行算成新增故障；
  • 历史 syslog 行不含年份，按本次故障包的日期背景解释，不能写成"原文自带完整年月日"；
  • 日志时间是驱动检测到异常的时刻，不一定是物理故障真正开始的精确时刻。跨采集源关联要结合 boot、UUID、单调时间与错误内容，不能仅按显示时刻推算因果。

这段历史说明：不能只归因于 595.99.02 独有的回归；但两个版本共有的驱动/固件问题仍然可能存在——两版都有记录是观察，不是控制了其他变量的驱动 A/B 实验。

5. 驱动版本怎么选：官方口径与三个误读

针对本案的 Linux x86_64、RTX 5070（GB205），后续获批维护时建议优先评估 595.104.02（Production Branch，Open Kernel Modules） 作为对照基线。依据：

核对项 官方资料给出的信息 使用方式
生产分支 2026-10-21 复核的 NVIDIA 公告列出 Production Branch 为 595.104.02 作为稳定性对照的优先候选
发布时间 595.104.02 为 2026-09-22；本机 595.99.02 为 2026-08-27 本机版本已不是该分支最新补丁
GPU 支持 595.104.02 固定标签的支持表明确包含 RTX 5070、2F04 确认型号受支持，不能保证本机无故障
内核模块类型 Blackwell 只支持开放内核模块 "换同版闭源内核模块"的排查建议不适用
新功能分支 另有 615.78.08 NFB 版本号更大 ≠ 更适合本案，也不等于修复 Xid 79

来源：NVIDIA 当前驱动公告、595.104.02 开放内核模块说明、595.104.02 固定版本支持表。

三个必须澄清的误读：

  • "官方当前生产分支"与"本机已验证稳定"是两件事。 595.104.02 的发布摘要列出 GPU 大页表分配、Wayland HDR 元数据等修复，未明确宣称修复本案这种 RTX 5070 Xid 79。它是建议的对照基线，尚未在本机安装或验证，不能承诺升级后不再掉卡；
  • Xid 表截图里的 “CUDA 12.7／R565” 不是推荐版本。 该内容位于 Xid 154 linkage 列，描述事件关联；截表格局部时很容易看错列，把它当成"5070 的推荐/最低驱动"；
  • 保持同版配套。 内核模块、用户态库和 GSP 固件要同版；不要在包管理安装上直接叠加 .run 安装器。实际维护还要核对发行版软件源、内核支持与包来源。

6. 社区有同类报告，但不能对号入座

有同类用户报告；尚不足以证明本机根因。 需要区分报告者的观察、报告者的推测和厂商已确认的结论：

公开材料 实际提供的证据 与本案的距离
NVIDIA 论坛：三张 RTX 5060 Ti、595.99.02 发生 Xid 79/154 发帖者提交故障包；后续更新称 595.104.02 仍复现 驱动版本匹配，但 GPU 型号（GB206）、内核与绑定方式不同；不是 5070 的受控复现
开源驱动仓库 Issue #1151 原始报告为 RTX 5080/595.71.05；评论中有 RTX 5070/595.71.05 的设备失联报告 同为 GB205 的评论值得跟踪，但该评论称最初 Xid 已被日志刷屏覆盖，不能补造其首个错误
论坛关于 bug 6426268 的回复 NVIDIA 支持指出该 bug 是另一问题、根因不同，分别跟踪 不能把所有 Blackwell 掉卡归入同一个"官方确认的固件 bug"

来源：5060 Ti、595.99.02 及升级后的报告、Issue #1151 及 5070 评论、关于 6426268 的后续澄清。

7. DKMS 截图"一片红"的三层误读

现场有一张 DKMS 构建日志截图，圈出了好几处"ERROR"。它有三层容易混淆的内容：

① ERROR: Kernel configuration is invalid 出现在命令文本里，不在执行结果里。 原始日志打印的是：

test -e include/generated/autoconf.h -a -e include/config/auto.conf || (
    echo >&2 "ERROR: Kernel configuration is invalid."
    # 后续错误提示与退出语句，此处仅展示条件结构
)

含义是：如果前面的文件检查失败，才执行括号内的错误分支。 构建日志把整条命令打印出来，不等于该错误分支已经执行。截图圈出 ERROR 字样，不能认定内核头文件缺失。

② pahole: not found 是真实的依赖缺失，但后果有限。 它反映构建环境需要核查；不过同一段日志后面能看到生成 nvidia*.ko 的链接命令，以及因没有 vmlinux 而跳过 BTF 生成的提示，随后的运行日志也确实加载了 595.99.02 模块。这支持"不能由该截图判定整个驱动未安装成功"，但不证明每个构建步骤都没有问题——该片段没有提供完整 DKMS 包装命令的退出码，Leaving directory 不能当成退出码 0。

缺失的构建辅助工具值得补齐，但目前没有证据把它与数小时后的设备失联建立因果关系。

③ 历史安装记录确有交叠，但不要串错版本和时间。 故障包内另有：590.44.01 安装器因 nvidia-uvm 仍加载而中止（旧安装尝试，不是当前 595 安装失败）；卸载 590 时发现部分原登记文件/链接已变为 595，提示安装内容曾被改变。结论是安装历史需要核查包归属与实际加载路径；既不能张冠李戴，也不能因为"当前核心版本一致、全文未检出 NVRM: API mismatch"就说软件环境完全干净。

另外两处典型误读：nvidia-settings 510.47.03 是 GUI 设置工具的版本，不能当作内核模块与 NVML 混装的证据；lspci 的 Kernel modules 列列出 nouveau，不等于 nouveau 已加载或正在绑定该 GPU。

8. nvidia-bug-report 日志怎么读：先找第一条异常

nvidia-bug-report.log 是采集包，不是一条按时间排列的日志：系统信息、历史安装日志、DKMS 日志、多章节内核日志、PCIe 状态依次拼合。

重复错误输出占据大量空间，文件大不等于发生了同样多次独立故障（例如整段的 0xffffffff / NV_ERR_GPU_IS_LOST 刷屏，只是掉卡后的重复后续）。QuickLook 只显示前 128 MB 时，会直接漏掉关键章节。

1.48 GB 日志导航

推荐阅读顺序：身份与版本 → 启动分段 → 第一条异常 → 后续错误 → 硬件快照。在持有原件的目录执行的检索命令（rg 为 ripgrep，没有时可用 grep -aEn 替代）：

LOG='./nvidia-bug-report.log'

# 实际模块版本、GPU 型号及故障事件；-a 避免二进制探测提前停止
rg -a -n -m 120 \
  'NVRM version:|NVRM: loading NVIDIA|GeForce RTX 5070|NVRM: Xid .*: (79|154),' \
  "$LOG"

# 只搜关键错误种类，不要直接打印所有 NVRM 行
rg -a -n -m 80 \
  'API mismatch|Unknown header type|PCIe Bus Error|AER:.*[Ee]rror|DPC:.*[Ee]rror' \
  "$LOG"

-m 限制输出条数；达到上限就要按特定时间/启动章节继续缩小检索，不能声称已经看到全部。全文没有命中也不等于该错误绝不曾发生（rg 退出码 1 通常只是"没有匹配项"）。

本案"未检索到 PCIe Bus Error、AER/DPC 错误事件、Xid 119/120"就是检索结果，不是排除硬件故障的结论——Linux 是否记录 AER 还受固件控制权和错误报告配置影响（Linux AER 说明）。

按行号读取远处窗口，逐行流式即可：

from itertools import islice

start, end = 6841780, 6841830
with open("nvidia-bug-report.log", "rb") as stream:
    for number, raw in enumerate(islice(stream, start - 1, end), start):
        print(f"{number}: {raw.decode('utf-8', 'backslashreplace').rstrip()}")

原包存在少量非 UTF-8 字节，按二进制逐行读、只对需要展示的行解码；不要以"修复编码"为由改写原包。核对窗口时确认所属章节、同次启动加载版本和 GPU 身份——不要把另一启动的版本、另一个 BDF 的错误或旧安装器日志拼成同一次故障。

时间顺序是因果讨论的前提。 本案 12:11:50 先掉总线，12:12:28 才出现 TLB 失效与 GSP RPC 错误——晚了约 38 秒，属于失联后的后续错误链。不能看到 “TLB”“GSP” 字样就颠倒顺序，声称它们先触发掉卡。

原件完整性（行号、SHA 均绑定以下原件）：

原件 字节数 SHA-256
nvidia-bug-report.log.gz 20,592,964 77c36f70…b462b5
nvidia-bug-report.log 1,476,792,697 97c65237…5690644

流式核验确认压缩包解出的字节数与 SHA 和解压文件一致；原始包保持不变，公开文章不附下载地址——包里包含完整机器配置与历史日志，给厂商时通过受限支持渠道传递。

至此，本案六条主要线索的证据边界可以汇总成一张图（前文各节均有展开）：

六条线索的证据边界

9. 区分"卡、线、槽、驱动"只能靠单变量实验

以下均为后续计划，尚未执行。先保存故障现场，再由供应商安排维护；硬件拆装应断电，PSU 模组线不能跨型号随意混用。

单变量对照 如果结果稳定复现，支持什么方向
有转接件时改为主板直插，其余不变 故障随转接件出现 → 支持该连接路径问题
换用适配且已验证正常的 PSU 与配套供电线 故障随原供电组件出现 → 支持供电路径问题
疑似卡放到正常主机，正常卡放回原主机 故障跟随卡 → 支持卡本体；跟随主机 → 支持平台问题
硬件、负载、内核、固件不变，仅更换完整一致的驱动版本 故障仅在某版本重复出现 → 增强版本回归证据
供应商指导下逐项比较 BIOS/VBIOS、PCIe 速率或电源管理设置 识别平台兼容性或触发条件，不等同于已找到损坏部件

每次保留同一组运行记录：GPU 身份、插槽/线材、软件版本、实际负载、温度与功耗时间序列、第一条 Xid、后续错误和恢复方式。偶发故障需要重复观察；一次重启恢复或一次短测通过，都不能宣布修复。

另外给已获授权主机的现场取证命令模板（BDF 须先由 lspci 确认，不能套用本例地址）：

# 1. 同屏记录采证时间、启动身份与已加载驱动
date -Is
cat /proc/sys/kernel/random/boot_id
uname -r
cat /proc/driver/nvidia/version
modinfo -F version nvidia

# 2. GPU 访问结果；超时是采证结果的一种，不自动重复
timeout -k 3s 10s nvidia-smi
printf 'nvidia-smi exit=%s\n' "$?"

# 3. 本例 GPU、同卡音频功能及上游桥；其他机器须替换为自己的 BDF
sudo timeout -k 3s 10s lspci -Dvvnnk -s 0000:01:00.0
sudo timeout -k 3s 10s lspci -Dvvnnk -s 0000:01:00.1
sudo timeout -k 3s 10s lspci -Dvvnnk -s 0000:00:01.1

# 4. 当前启动的错误摘要（截图用摘要，诊断仍需保存完整前后文）
sudo journalctl -k -b 0 --no-pager -o short-iso-precise |
  grep -E 'NVRM: Xid|GPU has fallen off|Node Reboot Required|PCIe Bus Error|AER:|DPC:'

timeout 用于限制等待；若进程陷入内核不可中断等待，时限也不能保证立即退出，不能继续堆积相同查询。退出码 124 通常表示超时，应如实记下。

10. 效果与总结

已确认 未确认 / 边界
同一 GPU 反复 Xid 79，故障后 PCIe 配置访问异常 根因未定：卡本体、供电、插槽/转接、软件组合均未排除
四次事件横跨 590.44.01 与 595.99.02，UUID 相同 不是严格驱动 A/B；不能排除两版共有缺陷
当前已加载模块/磁盘模块/NVML 版本一致 安装历史交叠需核查，不等于环境完全干净
故障包完整（采集退出码 0、gzip 校验、SHA 一致） 无 AER/温度/ PSU 前兆记录 ≠ 这些部件正常

四条经验：

  1. 先找同一次启动里的第一条异常，再解释后续错误——报错时间顺序反了，整个因果链就反了；
  2. 不要只看截图里有没有 ERROR——它可能躺在未执行的条件分支里，也可能是旧安装器的历史；
  3. 官方表格的版本号要看清列——Xid 154 linkage 不是推荐驱动；nvidia-smi 的 CUDA Version 也不是本机 CUDA Toolkit 版本；
  4. 社区相似症状是线索不是结论——型号、版本、绑定方式有一个对不上，就不能对号入座。

下一篇换一个更复杂的现场：8 卡服务器在 NCCL 测试中掉卡，如何用一次对调实验缩小故障范围——对调定位法：8 卡 RTX 6000D 掉卡，如何用对调缩小故障范围。

系列目录

  1. KV Cache 与前缀缓存：从原理到 99.9% 命中率的生产实践
  2. PD 分离实战：Prefill/Decode 拆池、配比拐点与容量规划
  3. GPU→内存→SSD 三级 KV 缓存：Mooncake 分层实战与跨引擎复用陷阱
  4. Kimi-K3 原始 MXFP4 权重512K 长上下文生产部署：双机 16 卡 TP8×PP2 与 CUDA Graph 调优
  5. 大模型压测方法论：如何让性能数据可信
  6. 推理集群可观测性：64 卡监控体系与缓存证据链
  7. MiniMax-H3视频生成服务化：ComfyUI 多 GPU 编排与长任务生命周期
  8. 掉卡排查实录：RTX 5070 反复 Xid 79，如何排查建立证据链（本篇）
  9. GPU对调定位法：8 卡 RTX 6000D 掉卡，如何用对调缩小故障范围
  10. CUDA 802 不是 NCCL 网络故障：H20 NVSwitch 物理链路排查实录
  11. DeepSeek-V4.1-Flash 双机 16 卡 H20 部署压测：TP8×DP2 与跨机 EP 的边界

数据声明：本文为单设备（n=1）故障的未闭环排查实录，所有结论均为证据边界内的工程判断，不构成根因定论。

AI vLLM SGlang