RTX 5090 高负载黑屏与 Xid 79 系统排查手册

最后更新：2026-07-15

适用机器：

• GPU：技嘉 RTX 5090
• CPU：AMD Ryzen 9 9950X
• 主板：华硕 TUF GAMING X870E-PLUS WIFI7
• 电源：安钛克 NE 1300 金牌，ATX 3.0，原生 12V-2x6
• 系统：Ubuntu 24.04.4 LTS
• 当前驱动：NVIDIA 580.126.20 open kernel module + GSP

1. 当前结论

当前已经完成驱动版本和受控功率负载对照。现有证据不支持继续把驱动版本作为第一嫌疑，应把排查重点放在：

1. 12V-2x6 插头、原装线材和 PSU 供电路径。
2. RTX 5090 本体，包括板上 VRM、GDDR7、PCIe 控制器和其他未暴露温度传感器的部件。
3. PCIe Gen5 链路、显卡插槽、显卡下垂和主板 BIOS。
4. 机箱内显卡与主板之间的局部热区和整体风道。
5. NVIDIA 驱动与图形显示路径，当前降为次要方向，但不能在逻辑上完全排除。

当前已经在 450W 复现 Xid 79，立即停止 500W、550W 和 600W 测试，也不要继续用完整 SmokeSeg 训练复现。重启后应先把功率限制恢复为 400W，再保存证据、断电检查连接和散热、更新稳定版 BIOS、做 PCIe Gen4 对照，最后进行双向交叉换卡。

1.1 已有证据

• 32/32 线程 CPU-only 压力测试持续 600 秒，CPU 达到 100% 使用率，所有 worker 正常退出。
• CPU 测试峰值温度为：
  • Tctl：85.9°C
  • Tccd1：88.1°C
  • Tccd2：85.2°C
• CPU 测试未复现黑屏、死机或重启。
• CPU 测试日志位于：
  • work_dirs/diagnostics/cpu_only_stress_20260715_111025.log
• 发生训练黑屏的上一启动周期中，内核明确记录：
  • Xid 79: GPU has fallen off the bus
  • GPU lost from the bus [NV_ERR_GPU_IS_LOST]
  • Xid 154: Node Reboot Required
  • 多个 GSP RPC 清理失败
• NVIDIA 580.126.20 已完成干净安装，当前没有 590/595 分支包混装；DKMS 已为 6.17.0-35 和 6.17.0-40 两个内核构建。
• 确定性的 GPU-only FP16 GEMM 在 400W 下：
  • 60 秒冒烟测试通过，退出码为 0。
  • 第一次 300 秒测试通过，平均功耗 399.8W，峰值 402.8W，最高 70°C，平均利用率 96%。
  • 第二次 300 秒测试通过，平均功耗 399.9W，峰值 402.8W，最高 70°C，平均利用率 97%。
• 相同工具、相同矩阵和相同软件环境仅把功率限制改为 450W 后：
  • 从 GPU 负载开始约 201.6 秒后失败，工具记录 CUDA error: unspecified launch failure，退出码为 5。
  • 失败前实际平均功耗 424.1W、1 秒采样峰值 438.9W、最高温度 70°C、平均利用率 97%。
  • 内核在 2026-07-15 16:37:36 记录 Xid 79: GPU has fallen off the bus，随后记录 Xid 154 和必须重启恢复。
  • 日志中没有在 Xid 79 之前出现明确的 AER 错误；这不能排除 PCIe 链路故障。
• 595.71.05 与 580.126.20 均出现过同型 Xid 79；用户历史上使用 590 时也只能确认 400W 稳定，不能证明其在更高功率稳定。

因此，CPU、SmokeSeg 数据管线、BD 代码、显存容量和 GPU 核心过热都已显著降级为低优先级。当前最强证据是可重复的功率相关性：400W 稳定，而允许更高功率后 GPU 从 PCIe 总线上失联。1 秒 nvidia-smi 采样会漏掉瞬时尖峰，不能把 438.9W 当成精确电气故障阈值。

NVIDIA 官方对 Xid 79 的解释是：驱动尝试通过 PCIe 访问 GPU 时，GPU 已不可访问；常见方向包括 PCIe 链路、硬件连接、GPU 故障，也不能完全排除驱动问题：

• https://docs.nvidia.com/deploy/xid-errors/archive/index.html
• https://docs.nvidia.com/deploy/gpu-debug-guidelines/

日志中的 pid/name=cursor 只表示 Cursor 恰好是发现 GPU 已经失联的客户端，不能据此认定 Cursor 是故障原因。GPU 失去驱动控制后风扇进入高转速保护状态，也不等于单纯过热。

1.2 当前平台快照

• GPU 重启后当前运行在 PCIe Gen5 x16，32.0 GT/s。
• GPU 默认及最大功率限制为 600W，最小可设功率为 400W。
• GPU VBIOS：98.02.2E.80.39。
• 主板 BIOS：0208，日期 2025-04-24。
• 当前 Linux 内核：6.17.0-40-generic。
• 当前 NVIDIA 驱动：580.126.20-open，纯 580 包栈并由 580.126.20 pin 包锁定。
• 已验证故障点：450W 功率限制下约 201.6 秒出现 Xid 79。
• 当前安全基线：每次重启后先手动设回 400W；功率限制可能在重启后恢复为 600W。
• 当前图形桌面的 Xorg、GNOME Shell 和 Cursor 均使用 RTX 5090。

以上只是 2026-07-15 的诊断快照。以后继续排查前，应重新采集并记录，避免软件升级后混淆结果。

2. 排查原则

2.1 最终目标

最终目标是在显卡默认 600W 条件下稳定运行，而不是长期依靠 400W 限功率掩盖故障。

400W 在排查期间仍然有价值：

• 作为已知安全基线。
• 用于确认系统和测试工具可以正常运行。
• 用于建立故障功率阈值。

2.2 操作原则

• 除了必要的安全处理，一次只改变一个变量。
• 每一步都记录时间、硬件设置、软件版本和结果。
• 优先运行短时间、确定性的 GPU-only 测试，不直接启动完整实验队列。
• 测试 600W 前必须确保 SSH 可用，最好让显示器由 9950X 核显驱动。
• 一次通过不能作为结论；关键条件至少重复 2～3 次。
• 一旦出现 Xid 79、烧焦味、接口变色、熔化或异常高温，立即停止继续加压。

3. 安全检查

在重新插拔显卡供电线或显卡前：

1. 正常关机。
2. 关闭 PSU 后部开关。
3. 拔掉交流电源线。
4. 等待残余电量释放。
5. 不熟悉拆装时，请师姐、师兄或熟悉装机的人现场协助。

禁止事项：

• 不要带电插拔 12V-2x6。
• 不要拆开 PSU 外壳。
• 不要把另一台模块化电源的线接到本机 PSU。
• 不要因为接口难插而强行扭曲、斜插。
• 不要使用来源不明的延长线、转接线或 90 度转接器。

NVIDIA 官方线材说明：

• https://docs.nvidia.com/nvidia-cable-management-guidelines-and-faq.pdf

4. 第一阶段：不拆机比较两台电脑

目标：确认“配置一样”是否真的包括 BIOS、VBIOS、驱动、内核和功率限制。

在本机和师姐电脑上分别执行：

1
2
3
4
5
6
7
8

uname -r
sudo dmidecode -s bios-version
sudo dmidecode -s bios-release-date

nvidia-smi --query-gpu=name,pci.bus_id,vbios_version,driver_version,power.default_limit,power.max_limit \
  --format=csv

ubuntu-drivers devices

填写对照表：

重点检查：

• 两张卡是否真的是同一具体子型号。
• VBIOS 是否相同。
• 师姐主板 BIOS 是否明显更新。
• 师姐使用的是否是另一个 NVIDIA 驱动或内核。
• 两台电脑是否使用不同插座、排插或 UPS。

当前截图已经证明两张卡的 VBIOS 不同，因此“硬件一样”尚不能视为严格成立。不要把师姐机器的稳定性直接归因于 580 驱动；应继续核对显卡背面标签、技嘉具体 SKU/Revision、VBIOS、PSU 和主板 BIOS。任何 VBIOS 更新都必须匹配本机精确 SKU 和 Revision，不得刷入师姐显卡的 VBIOS 文件。

5. 第二阶段：检查供电和安装

这一阶段比直接交叉换卡工作量小，而且直接针对 Xid 79 和功率相关性。

由熟悉装机的人协助检查：

• [ ] GPU 侧 12V-2x6 完全插到底。
• [ ] 卡扣已经锁紧，没有肉眼可见的缝隙。
• [ ] 如果 PSU 侧是模块化接口，PSU 侧也完全插紧。
• [ ] 使用该 PSU 自带的原装线材。
• [ ] 没有延长线、转接头或第三方 90 度转接器。
• [ ] 接口附近没有急弯，也没有被机箱侧板强压。
• [ ] 插头和插座没有发黄、变色、熔化、焦味或针脚异常。
• [ ] 显卡 PCIe 金手指完全进入主板插槽。
• [ ] 显卡挡板螺丝没有将显卡拉歪。
• [ ] 显卡支架有效，显卡没有明显下垂。
• [ ] 主板插槽和显卡周围没有异物。
• [ ] 显卡与主板之间没有被线材或其他部件堵成明显的风道死角。
• [ ] 机箱进风、出风和主板附近风扇在负载时确实升速。

如果发现变色、熔化或烧焦味，不要再次开机，应直接联系显卡、电源或整机售后。

GPU 核心只有 70°C 不能排除局部热问题。Linux 下可能看不到 GDDR7 结温、显卡背面 VRM、GPU PCIe 控制器或主板局部热区。完成插头和接口安全检查后，可以把“打开侧板并用外部风扇增强整体风道”作为一次有明确边界的热对照；它只用于判断方向，不能作为长期修复，也不要在通电状态下触碰或晃动线材。

还应进行一次低成本交流供电对照：

• 使用已知正常、容量合适的墙上插座或高质量排插。
• 暂时绕开来源不明的排插或 UPS。
• 不要与大功率设备共用明显过载的插座。

1300W 额定功率在规格上足够，并不能排除电源个体故障、线材问题、接触不良或瞬态响应异常。

6. 第三阶段：让 RTX 5090 脱离图形桌面

关闭 Linux 图形界面有诊断价值，但它不是修复方案。它要回答的问题是：

RTX 5090 只做 CUDA 计算时，是否仍然出现相同的 Xid 79？

6.1 推荐方案：使用 9950X 核显

1. 将显示器连接到主板 HDMI 或 DP。
2. 在 BIOS 中启用集成显卡，并将其设置为主要显示设备。
3. 启动系统。
4. 执行 nvidia-smi。
5. 确认进程列表中没有 Xorg、GNOME Shell、Cursor 等图形进程占用 RTX 5090。

这比单纯关闭图形界面更有价值：即使 5090 再次掉线，核显和 SSH 仍有机会保留系统控制权。

6.2 备选方案：临时进入纯命令行模式

先从另一台电脑测试 SSH 登录，并在 tmux 中操作。不要直接在即将被关闭的 GNOME Terminal 中启动测试。

临时关闭图形界面：

1
2

sudo systemctl isolate multi-user.target
nvidia-smi

确认 nvidia-smi 中已经没有 Xorg、GNOME Shell、Cursor 等图形进程。

测试完成后恢复：

1

sudo systemctl isolate graphical.target

此阶段不要永久修改默认启动目标，即暂时不要执行：

1

systemctl set-default multi-user.target

7. 第四阶段：建立持久监控

至少使用两个 SSH/tmux 窗口。

7.1 内核日志

1

sudo journalctl -kf -o short-precise

7.2 GPU 遥测

1
2
3
4
5
6

mkdir -p work_dirs/diagnostics/rtx5090

nvidia-smi \
  --query-gpu=timestamp,power.draw,power.limit,temperature.gpu,utilization.gpu,clocks.sm,clocks.mem \
  --format=csv -l 1 \
  | tee work_dirs/diagnostics/rtx5090/gpu_telemetry.csv

如果发生物理重启，重新开机后立即提取上一启动周期：

1
2
3

sudo journalctl -b -1 -k -o short-precise \
  | rg -i "NVRM|Xid|GPU has fallen|GPU_IS_LOST|AER|PCIe|GSP" \
  | tee work_dirs/diagnostics/rtx5090/previous_boot_gpu_errors.log

发生 Xid 79 后，应在重启并恢复到 400W 安全功率后保存完整证据：

1
2
3
4
5
6
7

mkdir -p work_dirs/diagnostics/rtx5090/580_450_failure

sudo journalctl -k -b -1 -o short-precise \
  > work_dirs/diagnostics/rtx5090/580_450_failure/kernel_previous_boot.log

sudo nvidia-bug-report.sh --safe-mode \
  --output-file work_dirs/diagnostics/rtx5090/580_450_failure/nvidia-bug-report.log

nvidia-bug-report.sh 可能自动在文件名后添加 .gz。提交售后前应检查报告中是否包含用户名、路径等不希望公开的信息。

7.3 如何解释黑屏时的系统状态

8. 第五阶段：GPU-only 功率阶梯测试

不要先跑完整 SmokeSeg/BD 队列。应使用同一个确定性的 GPU-only 负载，排除数据加载、训练代码和 CPU 负载的干扰。

说明：

• tools/stress_cpu_only.py 不能用于本阶段。
• 本仓库已提供 tools/stress_gpu_only.py；使用确定性的 CUDA GEMM 作为负载。
• 该工具支持固定时长、预热、温度保护、每秒 NVIDIA 遥测、持久化日志和异常退出码。
• 该工具只读取当前功率上限，不会自行修改功率限制。

先从 400W 开始，不要直接测试 600W：

1
2
3
4
5
6
7
8
9
10

sudo nvidia-smi -pm 1
sudo nvidia-smi -pl 400
nvidia-smi --query-gpu=driver_version,power.limit --format=csv,noheader

conda run -n GQA python tools/stress_gpu_only.py \
  --duration 300 \
  --warmup-seconds 15 \
  --expected-power-limit 400 \
  --max-temp 83
echo "exit_code=$?"

默认日志写入 work_dirs/diagnostics/：同名 .log 是逐秒状态，.csv 是功耗、温度、利用率、频率和显存遥测。每行都会立即刷新到磁盘；如果黑屏或重启，恢复后先查看时间最新的两个文件。--expected-power-limit 会在档位不匹配时拒绝启动，防止误在 600W 下压测。

退出码：

本机已经完成首次功率阶梯并在 450W 复现 Xid 79。因此当前不再继续寻找 425W/450W 之间的精确阈值，也不测试 500W、550W 或 600W。只有完成物理检查或单一变量修正后，才在 400W 重新建立基线，并只回到已知失败档 450W 验证该修正是否有效。

建议阶梯：

对应日志：

• work_dirs/diagnostics/gpu_only_stress_20260715_160722.log
• work_dirs/diagnostics/gpu_only_stress_20260715_161049.log
• work_dirs/diagnostics/gpu_only_stress_20260715_162019.log
• work_dirs/diagnostics/gpu_only_stress_20260715_163402.log

设置功率限制：

1

sudo nvidia-smi -pl 400

完成某项纠正措施后，如果要重新验证 450W，必须同时保留 --expected-power-limit 450，并确保 SSH、日志、核显显示或纯命令行环境已准备好。一次再次出现 Xid 79 就立即停止，不再重复该档位。

每个功率档位都应记录：

• 实际最高 power.draw。
• GPU 最高温度。
• GPU 利用率。
• 是否出现 Xid。
• SSH 是否仍可用。
• 是否需要物理重启。
• 第几秒发生故障。

一旦某档位出现 Xid 79，不再继续更高档位。

8.1 无图形界面的判定

一次无图形界面通过不能排除图形路径问题，关键档位至少重复 2～3 次。

9. 第六阶段：更新主板 BIOS

当前 BIOS 0208 较旧。华硕官方页面在 2026-07-15 可见：

• 稳定版 2306，发布日期 2026-06-17。
• 稳定版 2306 使用 AGESA ComboAM5 PI 1.3.0.1b。
• 测试版 2401，发布日期 2026-06-26，使用 1.3.0.1b Patch A。

官方页面：

• https://www.asus.com/motherboards-components/motherboards/tuf-gaming/tuf-gaming-x870e-plus-wifi7/helpdesk_bios?model2Name=TUF-GAMING-X870E-PLUS-WIFI7

建议：

1. 记录或拍照保存当前 BIOS 设置。
2. 下载稳定版 2306，不使用测试版 2401。
3. 在供电稳定、系统空闲状态下使用华硕官方方法升级。
4. 升级后加载默认设置。
5. 暂时保持 PBO、Curve Optimizer、EXPO/内存超频关闭或 Auto。
6. 先保持 PCIe Auto/Gen5。
7. 驱动保持 580.126.20 不变，避免同时更换多个变量。
8. 重启后立即把功率限制设为 400W，先完成一次 300 秒基线。
9. 400W 通过后，只回到已知失败档 450W 做一次验证；不要直接测试 500W 或 600W。

注意：部分新版 BIOS 可能限制回退。升级前必须阅读华硕页面的版本说明。社区中存在“更新 BIOS 后改变 Xid 79 频率”的报告，但也有发帖者后续撤回单一 BIOS 根因判断并转向局部散热；因此 2306 是合理的固件对照，不是承诺能够修复。

10. 第七阶段：驱动版本对照（已完成）

当前不再继续更换驱动：

• 595.71.05 下已经记录过 Xid 79、GPU lost、Xid 154 和 GSP RPC 清理失败。
• 580.126.20 下使用独立 GPU-only 工具在 450W 再次记录同型 Xid 79 和 Xid 154。
• 当前所有 NVIDIA 分支包、nvidia-settings、固件和 DKMS 均为 580.126.20，不存在旧分支混装。
• 400W 稳定、允许更高功率后失败的规律跨越了驱动版本，驱动特定回归的优先级已经明显下降。

继续排查期间保留 580 pin：

1
2

apt-cache policy nvidia-driver-580-open nvidia-dkms-580-open \
  nvidia-driver-pinning-580.126.20

除非以后获得 NVIDIA 明确针对该签名的修复说明，或者硬件/PCIe/BIOS 对照全部排除，否则不再通过安装 590、595、610 或切换开源/闭源内核模块来反复试错。

11. 第八阶段：固定 PCIe Gen4 对照

如果完成供电检查和 BIOS 2306 更新后，PCIe Gen5 在 450W 仍出现 Xid 79：

1. 在 BIOS 中把显卡主插槽从 Auto/Gen5 固定为 Gen4 x16。
2. 其他条件保持不变。
3. 启动后用 current_link_speed 和 current_link_width 确认已经是 Gen4 x16。
4. 先运行一次 400W、300 秒基线。
5. 400W 通过后只测试一次 450W；再次出现 Xid 79 就停止。

1
2

cat /sys/bus/pci/devices/0000:01:00.0/current_link_speed
cat /sys/bus/pci/devices/0000:01:00.0/current_link_width

判定：

Gen4 是诊断手段，不代表最终必须长期使用 Gen4。

不要在这一阶段盲目加入 pcie_aspm=off、pci=nommconf 等内核参数；这些参数会同时改变多个行为，并可能掩盖真正的问题。

12. 第九阶段：交叉换卡

只有前面的低成本排查仍无法定位时，才进行交叉换卡。由熟悉装机的人协助。

最有价值的是双向矩阵：

1. 把本机 RTX 5090 装到师姐电脑，使用师姐电脑自己的 PSU 和原装线。
2. 把师姐已知正常的 RTX 5090 装到本机，使用本机自己的 PSU 和原装线。
3. 两边先以 400W 建立基线，再使用已知失败档 450W、相同 GPU-only 负载和相同时长。
4. 不需要在交叉测试中直接使用 600W；450W 已足以区分本机已知故障。

只做“本机显卡装到师姐电脑”的单向测试也有价值，但结论不如双向矩阵完整。

再次强调：任何情况下都不要在两台模块化电源之间混用 PSU 线材。

13. 故障分支与下一步

13.1 供电或接口方向

满足以下任一条件时，优先检查/替换整套 PSU 与其原装线：

• 故障功率阈值非常稳定。
• 两张已知正常显卡都只在本机失败。
• 更换墙上插座没有改善。
• PCIe Gen4/Gen5 都失败。
• 显卡在另一台机器稳定。

如果要测试另一只 PSU，应更换“完整 PSU + 该 PSU 自己的原装线”，不能只换 PSU 而继续使用旧模块线。

13.2 GPU 本体方向

满足以下组合时，应准备显卡 RMA：

• 本机显卡在另一台已知正常机器也复现。
• 另一张已知正常显卡在本机通过。
• BIOS、驱动、PCIe Gen4/Gen5 和线材检查都不能解决。
• 450W 已稳定复现 Xid 79，而 400W 多次稳定。

13.3 主板或 PCIe 方向

满足以下条件时，优先联系主板售后或继续检查插槽：

• Gen4 稳定而 Gen5 稳定失败。
• 两张显卡都只在本机 Gen5 失败。
• 更新 BIOS 后现象发生明显变化。

13.4 驱动或显示路径方向

满足以下条件时，继续排查驱动/桌面组合：

• 5090 作为纯计算卡时多次通过。
• 让 Xorg/GNOME 使用 5090 后可以稳定复现。
• 切换驱动版本后现象随驱动版本变化。

此时可以长期让核显负责桌面、5090 专用于 CUDA，作为进一步验证；但仍应确认默认 600W 计算负载本身稳定。

13.5 局部散热方向

GPU 核心温度正常时，满足以下现象仍应检查局部散热：

• 故障只在持续负载数分钟后出现。
• 打开侧板并增强机箱整体风道后，故障时间明显延后或不再复现。
• 显卡体积遮挡主板、芯片组、M.2、VRM 或 CPU/内存控制器附近风道。
• Linux 无法读取 GDDR7 结温、显卡背板 VRM 或 PCIe 控制器温度。

外部风扇/开侧板只能作为一次变量对照。如果它改善稳定性，应重新规划进出风和风扇曲线，而不是长期敞开机箱；如果没有改善，就回到 Gen4 和交叉换卡，不继续盲目增加风扇转速。

14. 恢复稳定的验收标准

不能因为一次 5 分钟测试通过就宣布解决。建议满足：

• [ ] 600W GPU-only 测试连续通过至少 3 次。
• [ ] 每次均达到高 GPU 利用率和足够高的实际功耗。
• [ ] 内核没有 Xid、AER 或 GSP 致命错误。
• [ ] SSH、桌面和系统响应正常。
• [ ] 开启图形桌面后再连续通过至少 2 次。
• [ ] SmokeSeg 训练短跑通过。
• [ ] SmokeSeg 完整训练至少通过一个原先容易复现故障的阶段。
• [ ] 12V-2x6 接口没有异常气味、变色或物理松动。

只有仍依靠 400W 才能稳定，不算根因已经解决。

15. 售后证据包

如果最终需要联系技嘉、安钛克或华硕，建议整理：

• 完整硬件型号、序列号和购买信息。
• 主板 BIOS、GPU VBIOS、驱动、内核版本。
• 400W 两次稳定、450W 约 201.6 秒失败的受控测试表。
• Xid 79、Xid 154 和 GSP 错误日志。
• nvidia-bug-report.log.gz。
• GPU 遥测 CSV。
• 12V-2x6 接口和线材清晰照片。
• Gen4/Gen5 对照结果。
• 两台电脑双向换卡结果。
• PSU 或插座对照结果。

这些证据可以明确区分 GPU、PSU/线材、主板/PCIe 和驱动问题，避免售后只建议“重装系统”或“降低功率”。

16. 相关社区讨论与使用方式

以下讨论与本机症状相似，但都只是个案旁证，不能覆盖本机受控实验：

1. NVIDIA Developer Forums：Gigabyte RTX 5090、AM5/X870、Ubuntu、持续 CUDA 负载下出现 Xid 79。发帖者测试 580、595-open、595-closed、不同内核和显示服务器后仍会复现；最初怀疑 BIOS/AGESA，后续长期测试转而认为机箱/主板局部风道是关键变量，增强风道后稳定。
   • https://forums.developer.nvidia.com/t/bug-report-fix-rtx-5090-xid-79-gsp-firmware-crash-under-sustained-cuda-load/369440
2. NVIDIA Developer Forums：另一台 RTX 5090 在 590 和 595 上都记录 Xid 79/GSP timeout，说明跨驱动复现并非本机独有；但该用户在 400W 也会失败，与本机“400W 稳定、450W 失败”并不相同。
   • https://forums.developer.nvidia.com/t/rtx-5090-gb202-spontaneous-gsp-heartbeat-timeout-xid-79-gpu-has-fallen-off-the-bus-under-vulkan-load-and-idle/366352
3. Reddit LinuxHardware：一台用于 PyTorch 训练的 RTX 5090 在 Xid 79 前出现 PCIe AER/RxErr，用户报告重新安装显卡后改善。这支持检查 PCIe 接触、下垂和插槽，但本机本次故障前没有记录到同样的 AER，因此不能直接套用其结论。
   • https://www.reddit.com/r/linuxhardware/comments/1pkxkqa/gpu_fallen_off_bus_nvidia_5090_hardware_or_driver/
4. NVIDIA open-gpu-kernel-modules issue #900：RTX 5090 通过 OCuLink PCIe 4.0 x4 外接链路时，负载下稳定复现 Xid 79。它说明中间链路质量可产生同型症状，但本机是主板 CPU 直连 Gen5 x16，没有 OCuLink，不能直接类比。
   • https://github.com/NVIDIA/open-gpu-kernel-modules/issues/900

使用社区信息时遵循：

• 优先级始终是本机日志和一次一变量实验，高于帖子标题或单次“修好了”。
• 不因为帖子建议就同时加入 pcie_aspm=off、禁用 GSP、修改多个内核参数或刷新未知 VBIOS。
• 社区案例只用于生成候选假设：连接/供电、Gen5、BIOS、局部散热、GPU 本体；每个假设都必须在本机单独验证。
• NVIDIA 官方对 Xid 79 的定义仍是驱动经 PCIe 访问 GPU 时发现 GPU 不可达，常见方向包括 PCIe 链路故障、GPU 硬件故障或驱动问题：
  • https://docs.nvidia.com/deploy/xid-errors/analyzing-xid-catalog.html
  • https://docs.nvidia.com/deploy/gpu-debug-guidelines/

17. 推荐执行顺序摘要

1. 每次重启后先把功率上限设回 400W，停止 500W、550W、600W 和完整训练复现。
2. 保存 450W 失败的上一启动周期内核日志和 nvidia-bug-report.log.gz。
3. 完全断电，由熟悉装机的人检查并重新插紧 12V-2x6 两端和显卡，检查变色、焦味、急弯、下垂和风道死角。
4. 使用核显或 SSH，让 RTX 5090 脱离图形桌面；保持 580.126.20 驱动不变。
5. 将主板 BIOS 从 0208 更新到正式版 2306，加载默认设置并关闭 EXPO/PBO/Curve Optimizer；Gen5 下先测 400W，再只测一次 450W。
6. 如果 Gen5 仍失败，只把插槽固定为 Gen4 x16，重复 400W 基线和一次 450W 对照。
7. 如果 Gen4 也失败，进行双向交叉换卡；双方都使用各自 PSU 的原装线，已知失败档使用 450W 即可。
8. 如果师姐显卡也只在本机失败，测试“完整替换 PSU + 新 PSU 自己的原装线”；如果本机显卡在师姐电脑也失败，准备技嘉 RMA。
9. 只有某项修正已经让 450W 重复稳定，才恢复 500→550→600W 阶梯；任何档位再次出现 Xid 79 都立即停止。
10. 根据 Gen4/Gen5、双向换卡和完整 PSU 对照矩阵决定联系技嘉、安钛克或华硕售后。

最近用CodeX发现一个神奇问题，不管是Mac端的桌面app，还是VSCode/Cursor里的CodeX插件（等同于终端版），开始的第一次对话，总会显示五次重新连接，这需要耗费大概一分钟，关键是在这个过程中，等待地很折磨，怀疑是不是账号有问题还是梯子没挂好，但是在五次重新连接尝试后，突然就好了，又能回答了，后续的对话不用再等那么久，上网搜索原因，找到一篇帖子给了解决方法，但根据评论看，也会有些问题，所以还没实施，后续再找找别的办法

找到了非常简单的办法，那就是打开clash verge的tun模式，不要开全局，就是tun+规则，这样只要你购买的梯子（一般机场那边自己写好分流规则）的规则够好，就没问题，我目前就是这样，啥都没改，打开tun+规则模式即可，后续还想优化的话，可以去github翻最新的支持各种ai网站适配的分流规则加进来

包括手机上的小火箭也从GitHub找到了更好的分流规则，目前已经导入了，用手机远程连接codex更稳定。

另外还有一个经验贴，也收藏一下

另外现在更新后，codex和chatgpt合并，区分性没那么大，基本可以不再使用网页端；但我发现，在同一台电脑上，比如我的Mac和5090，无论是终端，还是插件，还是桌面app（Linux还没有桌面app），在同一台电脑上，都是共享对话的，共享codex设置的，比如Mac上，桌面app中的codex任务对话框，可以在vscode插件里面完整看到，但是插件和终端中功能不如app完整，app甚至还可以看到5090中的codex任务对话框，后面会跟着一个网络小图标，代表不在mac本地，可能因为我之前尝试过在mac的codex任务对话框中让它用ssh连接过5090，确实能连接上，而且能看到5090的文件，但没那么稳定，有时候点开可能会卡住

mac的桌面app现在改名叫chatgpt，已经没有codex桌面app了，二者融合，现在打开app，默认是codex的任务对话框，在这里面聊天目前，我认为跟网页chatgpt没有区别，都是用的5.6sol模型，回答差不多；而点击app中的聊天，可以看到跟chatgpt的聊天，这里的聊天是可以显示在网页端的，这不属于任务对话，这样的聊天可以在app中导入到codex任务对话中，比较方便，实现了之前我说的，跟网页端chatgpt对话进行头脑风暴，但是还得把这个复制给codex才能实现这个想法，现在可以直接导入，但是现在其实也不用再跟chatgpt在网页端进行对话了，直接在codex任务对话框进行对话，进行头脑风暴，完了之后再同一个对话框内直接让它实现

桌面app还有一个项目功能，可以选择将普通的任务对话框放进项目中，好处其实是方便管理，可以自己看到哪些对话跟这个项目有关，在插件/终端那边是看不到区分的，都属于历史任务对话

这又让我发现，Mac桌面app确实好用，我平常携带，使用，写论文按理说都是用mac，只有跑代码才用5090，甚至写代码都可以用mac进行远程连接ssh（但稳定性是个问题），但有个问题，在mac上与codex进行头脑风暴，想要将其实现的时候，最优解当然是直接在对话里让它ssh连接5090，我还没试过，但根据之前的尝试，能连上，那么说明应该能操作，但还是那句话，由于ssh我目前用的是免费的TailScale，不是那么的迅速稳定，然后转到项目文件夹，让它开始实现；第二个办法是，想办法复制/转述给5090这边到codex插件/终端（即使同一个账号，不是同一台电脑是不共享对话的，只是mac桌面app功能比较强大，能看到5090上的任务对话），这就比较麻烦了

那么，这启发了我，为什么不考虑全部在5090的codex插件/终端里面进行头脑风暴+想法实现呢？这好像更加方便，模型都一样，不用折腾ssh，可以直接本地实现，远程的话可以在mac上用todesk控制。唯一的问题就是，工作流的改变，这样的话，5090其实应该作为主力机了，至少创新/头脑风暴/写代码/跑代码/debug都在这上面，而mac可以做的事是ppt画图/写论文/todesk/看论文（但其实如果在代码本地文件夹直接让ai写是不是更方便，这个暂时保留mac上写），然而5090上也有zotero，同步配置已经完善，只能说后续可以多考虑，现在越来越方便了。

现在我发现，根本无所谓，想在哪里都可以，现在基本都互联，手机也远程连接了，可以在健身房指挥codex写代码，唯一不好的一点就是iPhone杀后台，手机不能切屏，否则就断开了，还要切回来重新链接等他继续跑，另外就是一点，发现extra high模式思考非常久，我都还没敢用ultra模式，以后打算多用用high模式。

最近打算基于把大气散射模型作为论文的一个重要的理论基础

也不乏有本领域的论文用到此模型，比如Trans-BVM和FoSp

但是目前我仍旧怀疑其公式推导的正确性，以及使用的合理性和正确性

于是搜集网络资料，找到一些原始推导,以及这篇

等博主在研究一段时间后，本博客将主要针对大气散射模型在深度学习中的应用进行补充

而且据我所知，在图像抠图领域，也有类似的模型。

Claude Code（以下简称CC）是Anthropic推出的命令行AI编程助手，原生使用Claude系列模型。但Anthropic官方API的价格较贵，而DeepSeek提供了官方的Anthropic兼容API端点，可以以极低的成本将DeepSeek模型接入CC。本文将记录在终端CC和VSCode CC插件中接入DeepSeek-V4-Pro的完整配置过程。
参考链接：Deepseek接入CC的官方文档
VsCode中的CC插件使用教程
B站视频教程：在VsCode-Claude-Code插件中接入DeepSeek教程

另外，CC本身是免费的，如果开通了claude的pro计划，可以在里面使用claude原生模型，最近找到了充值方式，首先你需要一个claude账号，这一步目前来说好像不是那么简单（容易封号），而我是前几年就有了，当年还是从闲鱼找人帮我注册的，花了10块，然后需要一个苹果手机，需要一个美区（或者不限制的区域）苹果账号，此时下载Claude的app，直接在app里点升级pro，自动弹出app付款，此时需要app store里面登陆美区账号付款的，在此之前使用支付宝礼品卡给美区账号充值🔪

碰到了问题，由于接入这个DeepSeek后，本人开通了付费的Claude，我怀疑正是因为之前手动改了CC的接口地址，导致被他们官方查到了IP，目前我的三年稳定的Claude账号被封了，本人已经转向codex。

使用codex后，碰上了gpt-5.6-sol，配上刚刚合并的gpt和codex桌面应用，以及mac，非常好用，还有iPhone远程连接，很好用，并且不打算再折腾国产接口接入了，害怕再被封。

实验管理与评测脚本说明（mmseg 自定义工具链）

本文介绍在本项目（基于 MMSegmentation 1.x）里自建的一套实验管理 + 评测工具，
用于解决"多次跑同一模型不同超参会互相覆盖"“结果难以横向对比”“评测要分尺寸/分子集”
等问题。全部改动只在 my_configs/paths.py 与 tools/*.py，不触碰 mmseg 内核，
训练/评测的数值与官方 tools/train.py / tools/test.py 完全一致。

涉及文件：

• my_configs/paths.py：路径与台账核心逻辑（tools/experiment_paths.py 转出供脚本用）
• tools/train.py：训练（带运行隔离 + 台账）
• tools/smoke_test.py：单次测试（指标 + 可视化 + 台账）
• tools/smoke_test_multiscale.py：分划分一键测试（自动发现，数据集无关）

结合最近一段时间的科研实践（主要是论文复现）以及 Datawhale 的公众号经验贴，这里整理一些使用 CodeX / Claude Code 这类编程 Agent 辅助科研开发的经验。

核心思路可以概括为一句话：模型能力固然重要，但上下文、长期规则和验收标准同样重要。

另外补充一点，如果是实战派，也就是工作/实习，也推荐最近看到的一篇很好的CC的实践指南

总工作流

比较稳定的一套流程是：

读上下文 -> 写计划 -> 确认范围 -> 小步实现 -> 跑验证 -> 总结结果 -> /new 开新对话

Agent 很适合做“有明确边界的工程任务”，但不适合在上下文混乱、目标模糊、验证缺失的情况下自由发挥。因此，每次让它动手之前，都要先让它理解项目、对齐任务，并明确最后如何验收。

先交代一下硬件配置：

• 显卡：技嘉 RTX 5090 纯血版
• CPU：AMD 9950X
• 主板：华硕 X870E-PLUS WIFI7
• 固态：三星 990 Pro 2TB
• 机械硬盘：西部数据紫盘 2TB
• 机箱：安钛克 FLUX SE
• 电源：安钛克 NE 1300 金牌（1300W，ATX 3.0，原生 12V-2x6）
• 风冷散热：九州风神 阿萨辛4
• 内存：美商海盗船 DDR5 5200 32G×2
• 系统：Ubuntu 24.04.4 LTS，内核 6.17.0-29-generic
• 驱动：NVIDIA 590.48.01（开源内核模块 + GSP），CUDA Runtime 13.1/12.8

最近在跑深度学习训练时，接连遇到几类不同表现的黑屏和 GPU 掉盘问题。起初我以为在 BIOS 里禁用核显就能解决，但实际测试下来发现问题仍然存在。经过日志排查和限功耗验证，最终确认：这不是显存不足，也不是代码问题，而是 RTX 5090 满功耗下的瞬时功耗尖峰触发供电保护，导致 GPU 掉出 PCIe 总线（Xid 79），简单来说就是开始跑代码的一瞬间功率过大，触发供电保护。

前言

Git 是开发中绕不开的版本控制工具，但其包含的命令和底层概念非常多。在实际的日常代码管理中，很多时候我们只需要用到它的一小部分核心功能。

为了提高工作效率，我在这里整理了一份自己平时最常用到的 Git 操作清单，主要涵盖了本地代码的暂存、提交、历史回退以及与远程仓库的交互。这份记录以实用为主，方便在忘记具体指令时随时查阅。

最近在处理烟雾分割任务时，发现现有的语义分割评估指标在应对特定分布（如目标极其微小、类别极度不平衡）时存在一些统计上的盲区。为了更客观地衡量模型性能，我对常用的评价指标进行了梳理，并记录了在 MMSegmentation 框架下实现自定义烟雾分割评价指标的过程。

在配置基于 RTX 5090 的深度学习环境时，由于底层硬件架构较新，框架版本的匹配需要特别注意。本文主要记录了在 RTX 5090 上配置 MMSegmentation 环境的过程，以及如何使用自定义数据集跑通基础的训练和测试流程。