GPU 机崩溃监控系统（2026-09-03 部署）

目的：复现视频生成时，抓取断电/崩溃前最后时刻的 GPU、系统、内核状态。 针对上次事故教训：整机断电时本地日志瞬间丢失（journald "uncleanly shut down"）， 唯一可靠的是实时 UDP 外发——数据在掉电前一秒已到本机。

架构

GPU 机 (192.168.31.25)                      DSH 机 (192.168.31.76)
crash_monitor.sh  ──UDP 9333──▶  crash_monitor_collector.py
  每 2 秒采样:                              监听 0.0.0.0:9333
  · 系统负载 loadavg                        落盘:
  · 内存 total/free/avail                    dl-hub/06-ComfyUI-H3运维记录/crash-monitor/gpu_monitor.log
  · GPU: 温度/功耗/利用率/显存/PCIe gen/width
  · 内核错误行实时转发: Xid/NVRM/panic/Oops/
    BUG/hung_task/soft lockup/thermal/OOM/Killed
  （dmesg -w 有权限则生效，无权限跳过）

组件与位置

组件	位置
GPU 机监控脚本	GPU 机 /home/zyw/crash_monitor.sh（本地副本 ~/Downloads/crash_monitor_gpu.sh）
本机收集器	本机 /home/zyw/Downloads/crash_monitor_collector.py（后台 job bash-3）
数据落盘	/home/zyw/Downloads/dl-hub/06-ComfyUI-H3运维记录/crash-monitor/gpu_monitor.log

启停命令

# GPU 机启动（nohup 脱离终端，掉 SSH 也不停）
nohup bash /home/zyw/crash_monitor.sh > /tmp/crash_monitor.out 2>&1 &

# GPU 机停止
bash /home/zyw/crash_monitor.sh stop
# （兜底）pkill -f crash_monitor

# 本机收集器启动（DSH 机）
python3 /home/zyw/Downloads/crash_monitor_collector.py

数据行格式

S|<UTC时间>|load=1m,5m,15m|mem_t=总kB,f=空闲kB,a=可用kB|gpu=温度_功耗W_利用率%_显存MiB_gen_宽度
KERNEL|<UTC时间>|<内核错误行>

示例：S|2026-09-03T07:47:41.918Z|load=0.01,0.04,0.10|mem_t=32653456kB,f=26499676kB,a=29305272kB|gpu=50_10.18_0_154_1_8

解读：GPU 50°C、功耗 10.18W、利用率 0%、显存 154MiB、PCIe gen=1、width=8。 （空闲时 gen=1 正常；满载推理时应看到 gen↑、功耗↑、利用率↑。）

复现流程

1. 确认 GPU 机监控进程在跑（pgrep -af crash_monitor）+ 本机收集器在跑（job 或 ss -ulnp | grep 9333）；
2. 正常跑一次视频生成（预计 ~20 分钟）；
3. 若再次断电：重启 GPU 机后，本机日志文件里掉电前最后一条记录就是临终数据；
4. 分析重点：最后若干条 GPU 功耗/温度/利用率趋势、PCIe gen 是否突变、 KERNEL 行有无 Xid/NVRM/panic；
5. 对照系统日志（journalctl --list-boots、last -x）确认断电时刻。

已知限制

• UDP 无确认，极端情况下丢包（本场景可接受，2 秒粒度足够）；
• 内核错误行依赖 dmesg -w 权限（sudo 组可看；zyw 在 adm 组）；
• 只能覆盖掉电前 ~30-60 秒的高频数据（2s×15 分钟 ≈ 450 行，日志文件持续增长）。

---

2026-09-03 16:52 复现事故记录（监控首秀，完整捕获）

现象：用户跑生成时 ComfyUI 再次断联，GPU 机第三次整机断电（前两次 15:00:25、本次 16:52:50）。

监控捕获的关键数据（本机日志 gpu_monitor.log，1982 条采样，2s 粒度）：

• 满功耗（>170W）持续 14.9 分钟（15:51:40 → 16:52:50），临终时刻 GPU 100% 利用率、179.87W、72°C；
• 全程温度 40-83°C，临终 72°C —— 无过热；
• PCIe 链路全程 Gen5×8 稳定（gen=5,width=8 直到断电）—— 推翻"掉总线"假设；
• KERNEL 错误行：0 条 —— 无 Xid/NVRM/panic/OOM/thermal 任何内核告警；
• 数据在 16:52:50.805 戛然而止，之后零记录 —— 整机瞬时断电特征。

结论：第三次同一模式（满载推理中瞬时断电、无任何软件/内核/温度/链路前兆）， 基本锁定 电源侧故障（PSU 保护触发/供电不稳），与 GPU、驱动、PCIe、温度均无关。

建议：优先排查/更换 PSU，检查 12V 供电线与插排接触；考虑 UPS 记录市电事件。

---

2026-09-03 17:16 重启后诊断（第三次事故后）

现象：第三次整机挂死（16:52:50），但用户观察到显示器仍有信号、操作无响应 → 推翻"断电"结论，确认为内核/驱动硬挂死（机器有电，系统无响应）。WOL 无效 + 显示器有信号 = 机器处于 S0 挂死，非 S5 关机。

重启后检查结果：

• ✅ ComfyUI 手动拉起（start_comfyui_v6.sh，pid 2303，8189 LISTEN）；
• ✅ 监控已重启，数据流恢复（本机 gpu_monitor.log）；
• PCIe 链路：空闲 gen=1（正常降档），满载时监控证实 Gen5×8 稳定；
• BERT 表：固件（Intel EDK2）在非正常关机后写入 BERT 表（BootErrorRegion 17196 字节 @0x75da1018）， 但内核 "Skipped 1 error records"——错误记录无有效 CPER 签名或严重度未标记， 固件未记录到可解析的具体硬件错误（或可恢复事件未被消费）；
• 无 NVRM/Xid/panic/OOM/thermal 任何内核告警（journal + syslog + kern.log 交叉验证）。

修正后的根因方向：三次均为满载推理时瞬间硬挂死、无任何软件/温度/链路前兆、机器有电。 监控数据（临终 100%利用率/180W/72°C/Gen5×8/零错误行）排除了 PCIe 掉线、过热、驱动报错； 结合 PCIe 链路速率异常（本次开机 Gen4 枚举 vs 运维基线 Gen5），高度怀疑显卡供电/接触或 电源轨在满载时不稳定，导致 GPU 驱动/内核死锁（区别于上次仅"掉总线"的轻症，本次为拖死整机）。

后续措施：

1. 安装 rasdaemon，下次 BERT/CPER 可精确解码；
2. 建议满载复测 + 监控抓取（若复现，临终数据已能定位）；
3. 考虑 nvidia-smi -pl 限功耗测试（隔离电源 vs 显卡问题）；
4. 检查显卡/供电线物理接触。

---

2026-09-03 23:29 第四次事故（监控完整捕获死亡瞬间）

现象：用户报告"突然重启了"。监控数据在 23:29:30.953 戛然而止（本机时间）。

死亡瞬间数据（本次监控全程 8327 条采样，2s 粒度）：

• 临终 5 条：GPU 100% 利用率、~180W 满功耗、76-82°C、显存 11GB、PCIe Gen5×8 稳定；
• 满载窗口：18:45 → 23:29（31.7 分钟 >170W 持续）；
• 温度范围 41-83°C，临终 82°C —— 无过热；
• KERNEL 错误行：0 条（无 Xid/NVRM/panic/OOM/thermal）；
• 数据戛然而止 = 整机瞬时死亡，无任何前兆。

与前三事故完全同模式：满载推理中瞬间死亡、机器有电（显示器有信号）、零内核告警、 PCIe 链路正常。第 4 次确认：指向电源/供电在满载时的硬件级故障（PSU 保护或电源轨失稳）， 非软件、非驱动、非过热、非 PCIe 掉线。

待机器恢复后检查：rasdaemon 数据库（本次已装，若固件写入 BERT/CPER 将可解码具体错误类型）。

---

2026-09-03 23:29 第四次事故分析结论（监控完整覆盖）

临终数据（23:29:30.953 最后采样）：GPU 100%/180W/82°C/显存11GB/PCIe Gen5×8 稳定， 随后数据流戛然而止。本次为rasdaemon 首次在场的事故，结果：

检查项	结果
rasdaemon（MCE/内存/PCIe AER/Extlog）	全部零错误
BERT 固件记录	无（上次有但 Skipped）
内核错误行（2s 粒度监控全程）	0 条
journal 最后记录	15:25:01 UTC 常规 cron，之后正常日志停止
journald	uncleanly shut down（非正常关机）
恢复	3 分钟内回到在线（用户侧重启/掉电自恢复）

四次事故共性（结论性）：

1. 全部发生在 GPU 满载推理（~180W 持续）期间；
2. 2 秒粒度监控无任何前兆（功耗/温度/链路全部正常至最后一条）；
3. 零内核错误（无 Xid/NVRM/panic/OOM/thermal）；
4. rasdaemon 在场仍零 MCE/内存/PCIe 硬件错误 → 排除 CPU/内存/PCIe 硬件故障；
5. 机器有电但系统死（显示器有信号）= 硬挂死/瞬间断电；
6. 指向电源侧：GPU 满载时 PSU/供电轨失稳，触发整机掉电或保护。

建议（按优先级）：

1. 更换/测试 PSU（主要怀疑对象；180W GPU + 满载持续时供电失稳）；
2. 检查插排/墙插/12V 供电线接触；
3. 可试 sudo nvidia-smi -pl 150 限功耗跑一轮，若限功耗后不再死机 → 电源问题实锤；
4. 考虑 UPS（区分市电闪断与 PSU 自身问题）。

---

2026-09-05 突破性发现：GPU 掉总线（Xid 79）为最终根因

上报时刻：用户 9/5 报告"突然重启"，查询到内核级报错——前几次"零错误瞬间死亡" 其实是 Xid 79 掉总线后驱动直接触发 Xid 154 OS 重启，不留错误记录的假象。

铁证（三次掉总线，全部同款）：

9/5 06:48:59  Xid 79, name=nvidia-smi, GPU has fallen off the bus
9/5 10:55:19  Xid 79, GPU has fallen off the bus
9/5 12:26:51  Xid 79, GPU has fallen off the bus  ← 本次上报
9/5 ...       Xid 154, GPU recovery action changed to OS Reboot

• Xid 79 = GPU 从 PCIe 总线掉线（驱动侧铁证）；
• Xid 154 = 驱动恢复动作 = 重启 OS → 这就是"突然重启"的直接原因（非人工）；
• 伴随大量 API_GPU_ATTACHED_SANITY_CHECK failed、UVM slab BUG、Flip event timeout；
• rasdaemon 零错误：掉总线是 PCIe 链路层物理事件，非 MCE/内存/CPU。

结论：非电源、非插座、非过热、非软件 bug —— 这是 8 月修过的 "GPU 掉总线"复发（NVreg_DynamicPowerManagement=0x00 已确认生效， Secure Boot 关闭，无拦截），剩余唯一怀疑：显卡/PCIe 物理接触。

建议（物理排查）：

1. 重新插拔显卡 + 12V 供电线（金手指/插槽接触）；
2. BIOS 检查 PCIe 链路速率设置，可固定 Gen4 求稳；
3. 有条件换第二条 x16 槽测试；
4. 若复现，抓 nvidia-bug-report 提交分析。