# 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` |

## 启停命令

```bash
# 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 提交分析。