DGX Spark 黑屏死锁故障诊断报告
硬件：NVIDIA DGX Spark (GB10, aarch64) | 系统：Ubuntu 24.04 LTS | 内核：6.11.0-1016-nvidia | 驱动：580.95.05 Open Kernel Module
一、我遇到的问题
1. 开机黑屏 + 主机发烫
早上按下主机电源键开机后，屏幕没有正常显示桌面，一直黑屏。但主机处于开机状态——风扇在转，机器持续散发明显热量，GPU 在空转发热。我短按了一下电源键想触发关机，但关机流程卡住了：屏幕没有变化，机器也没有关闭，持续发热。最终我只能长按电源键强制硬关机，等了一会儿再重新开机才恢复正常。
2. 偶发的界面卡死（按 Win 键可恢复）
除了那次严重的黑屏死锁，平时使用中还有一个间歇性问题：桌面界面会突然卡死——画面完全不动，鼠标键盘似乎无响应。但我发现按一下键盘上的 Win 键，再按一下，界面就能恢复原样，继续正常操作。这个现象不是每次开机都出现，而是偶发的，有时一天出现几次，有时几天不出现。
3. 鼠标移动变慢（非带宽问题）
另一个间歇性问题是鼠标光标移动变得很慢、很迟钝。以前遇到鼠标慢，是因为远程连接的带宽被占满了，但现在的场景下带宽完全没有占满，鼠标却依然很慢。我无法解释为什么会这样——难道后台有隐藏进程在消耗资源？但我确认过这台机器没有任何开机自启程序。
二、根因分析
通过 journalctl 还原了故障 boot（boot -2）的内核日志，故障过程如下：
时间线
08-09 13:31 ~ 08-10 04:57（boot -3）：昨晚正常工作会话，04:57 正常关机（Reached target poweroff.target）
08-10 10:56 ~ 11:09（boot -2）：故障 boot，开机后黑屏，关机卡死，最终硬关机
08-10 11:22:49 ~ 11:22:52（boot -1）：异常 boot，仅持续 3 秒（刚启动 X 就被切断，疑似释放静电后的首次尝试）
08-10 11:34 ~ 现在（boot 0）：当前会话，一切正常
boot -2 的内核日志还原了卡死过程
11:02:41 — X server 启动，加载 NV-GLX / NV-CONTROL（"NVIDIA 加载界面闪过"就是这一刻），随后显示黑屏。日志中记录了 NVIDIA 驱动内部 ZBC（Zero Block Color 压缩相关）对象查找失败。这是 GB10 上游 Open Kernel Module 在 aarch64 上的已知缺陷，导致 modeset 资源未能正确初始化。
短按电源键触发 systemd 关机后，nvidia-persistenced（PID 1489）进入 D 状态（不可中断睡眠），连续触发 4 次 hung task 警告（内核的 hung task「看门狗」机制——一种内核级软件定时器，与「硬件看门狗」（Watchdog Timer）不同，它检测的是进程级别的卡死，超时后仅输出告警日志而非触发硬件复位）。该进程在关闭 /dev/nvidia-modeset 设备文件时，调用 nvkms_close → down() 试图获取一个永远不会被释放的内核信号量。X server 因 ZBC 查找失败卡在 nvkms_yield 循环中（一个自愿让出 CPU 的等待循环，没有退出条件），持有该信号量永远不释放。
systemd 连续 3 次超时 kill 都失败——SIGKILL 对 D 状态进程无效，因为进程正在内核空间执行不可中断操作。进程从 11:04:11 卡死到 11:09:07，共约 6 分钟。
此外，系统未自动恢复——DGX Spark 平台具备「硬件看门狗」（Watchdog Timer，一种独立于 CPU 的硬件定时器，详见第五节），但其超时周期远长于本次死锁持续时间，「硬件看门狗」（Watchdog Timer）尚未到达触发阈值（详见第五节分析），硬关机成为当时的唯一出路。长按电源键强制断电让 GPU 冷启动，清除所有内核状态后重新开机恢复正常。
关于偶发界面卡死和鼠标变慢
界面卡死（Win 键恢复）的原因是 GNOME 合成器（Mutter）依赖 GPU 进行画面合成。NVIDIA 驱动内部间歇性的信号量竞争或 GPU stall 会导致合成器短暂冻结，表现为画面不动。按 Win 键触发 GNOME Shell 重新绘制 Activities 概览，相当于给合成器发送强制重绘信号，如果 stall 是瞬时的，画面就能恢复。
鼠标变慢的原因是鼠标光标由 GPU 硬件光标层渲染，不经过网络带宽。NVIDIA 驱动在中断上下文中做过多工作会导致内核调度延迟（DPC latency）飙升，表现为输入设备响应迟钝。这与带宽无关，是 GPU 渲染管线和内核调度的问题。
两个症状的根因统一指向 NVIDIA 580.95.05 Open Kernel Module 在 GB10 上的驱动缺陷。
三、排除项（已逐一验证）
以下假设全部排除：
ComfyUI 自启服务：系统级 + 用户级 enabled services 无任何 comfy/conda/python 项
crontab @rebootreboot：no crontab for zhanglifan
桌面 autostart：用户级 enabled 全是桌面组件（pipewire/gnome-keyring/ibus 等），无异常
6 个 conda 环境冲突：关机时无任何 ComfyUI 进程（boot -2 日志全程无 python/main.py）
KVM/GIC 中断冲突：KVM 模块加载了但 GICv3/GICv4 初始化正常（kvm [1]: vgic interrupt IRQ9 正常）
SMMU/IOMMU 故障：3 个 arm-smmu-v3 实例初始化正常，设备正常加入 iommu group
OOM：无任何 oom-kill / Killed process 记录
Kernel Panic：无 panic / Call Trace（除 hung task 外）
文件系统错误：boot -3 正常 unmount，无 I/O error
温度：当前 GPU 45°C、CPU 正常，发烫是死锁期间 GPU 未 idle 的副作用
四、这是一个已知的 NVIDIA 驱动缺陷
这个 bug 并非个案。在 NVIDIA 官方开发者论坛上，已有多个用户报告了完全相同的 nvkms_close 信号量死锁问题：
1. 论坛帖子 #367587（2026-04-23）
报告者使用 RTX 3050 (GA107)，驱动 580.126.09，内核 6.17.0-20-generic。症状完全一致：进程关闭 /dev/nvidia-modeset 文件描述符时在 nvkms_close → down() 上无限阻塞，Xorg 卡在 nvkms_yield 循环中持有信号量不释放，ghostty 进程 D 状态 1228 秒，SIGKILL 无效，只能硬重启。报告者抓到了精确的内核栈。
2. 论坛帖子 #371009（2026-05-22）
报告者使用的正是 DGX Spark / GB10，驱动 580.142，内核 6.17.0-1018-nvidia。在 Xorg 注销时 nvidia_modeset DisplayPort 路径发生 soft lockup，Xorg 和 nvidia-modeset 内核线程互相死锁，522 秒未恢复，只能 chassis reset。NVIDIA 官方工程师 aniculescu 于 2026-07-03 回复称"在最新更新上无法复现"并标记为已解决，但从未发布专门的修复公告。
3. 论坛帖子 #370539
报告者使用 RTX 5070 Ti (Blackwell)，驱动 580.159.03。Xid 79 / Xid 119 级联，静默 idle 挂起。报告者指出该问题在 580.82.x 之前也存在（至少追溯到 565.77），是长期存在的架构级缺陷。
我的情况与帖子 #371009 的硬件完全相同（DGX Spark / GB10），但驱动版本更早（580.95.05 vs 580.142），触发场景不同（开机黑屏后关机 vs Xorg 注销）。这表明该 bug 跨越了 580.95.05 到 580.159.03 的多个版本，在不同场景下都会触发。
值得注意的是，最新的 580.173.02 驱动在部分 DGX Spark (OTA2607) 上会导致 GPU 完全不可用（nvidia-smi 报告 “No devices found”），存在回归 bug。因此不能通过简单升级驱动来修复此问题。
五、关于「硬件看门狗」（Watchdog Timer）的技术说明
在第二节根因分析中提到，系统死锁后未能自动恢复，涉及「硬件看门狗」（Watchdog Timer）机制。以下对其工作原理、在 DGX Spark 平台上的具体实现、本次故障中未触发的原因，以及如何自定义超时时间做详细技术说明。
5.1 什么是「硬件看门狗」（Watchdog Timer）
「硬件看门狗」（Watchdog Timer）是一种独立于 CPU 的硬件定时器，用于在操作系统完全无响应时自动恢复系统。其工作原理为：操作系统在正常运行期间，需要定期向该定时器发送"心跳"信号（俗称"喂狗"），重置倒计时。如果操作系统因死锁、内核恐慌等原因停止响应，无法继续"喂狗"，倒计时归零后，定时器将触发硬件级系统复位（hardware reset），强制重启整个机器。
与之区分的是内核中的 hung task「看门狗」——这是一种软件定时器，检测进程级别的卡死（如 D 状态超过 120 秒），超时后仅输出告警日志，不触发硬件复位。两者机制不同，不可混淆。
5.2 DGX Spark 上的 SBSA Generic Watchdog
DGX Spark / GB10 平台使用的是 ARM SBSA Generic Watchdog（ARM 服务器基础架构标准通用看门狗），这是 ARM 服务器平台的标准看门狗硬件。该看门狗采用两阶段超时机制：
第一阶段（WS0）：超时后触发中断，通知操作系统进行紧急处理（如触发内核恐慌以收集崩溃日志）
第二阶段（WS1）：超时后执行真正的硬件复位（hardware reset），强制重启系统
在 NVIDIA 开发者论坛上，DGX Spark 用户通过 wdctl 命令确认了该看门狗的存在及其参数。部分用户报告的完整超时周期约为 20 分钟（两阶段合计），也有用户观察到单阶段超时为 10 秒——实际超时值取决于固件（BIOS）配置。
5.3 本次故障中为什么没有触发
本次死锁从 11:04:11（首次 hung task 警告）到 11:09:07（用户手动硬关机），仅持续了约 6 分钟。如果「硬件看门狗」（Watchdog Timer）的超时周期为 20 分钟，那么计时器尚未到达触发阈值，用户就已经通过长按电源键手动干预了。
如果当时没有手动硬关机，系统在约 20 分钟后理论上会被「硬件看门狗」（Watchdog Timer）自动复位。但这意味着需要额外等待约 14 分钟，对于一台 GPU 正在空转发烫的机器来说，这个等待时间并不理想。
5.4 如何检查 DGX Spark 上「硬件看门狗」（Watchdog Timer）的状态
以下命令可以通过 SSH 远程执行，也可以在 DGX Spark 连接显示器时在本地终端执行：
\# 1. 检查看门狗设备是否存在
sudo wdctl
\# 2. 检查 sbsa_gwdt 内核模块是否已加载
lsmod | grep sbsa_gwdt
\# 预期输出：sbsa_gwdt 20480 1
\# 3. 检查内核日志中的看门狗信息
dmesg | grep -i 'sbsa.\*watchdog'
\# 预期输出：sbsa-gwdt sbsa-gwdt.0: Initialized with 10s timeout @ 1000000000 Hz
\# 4. 检查 systemd 是否启用了看门狗喂狗
grep -i 'RuntimeWatchdogSec' /etc/systemd/system.conf
\# 默认值：#RuntimeWatchdogSec=0（未启用）
5.5 如何自定义「硬件看门狗」（Watchdog Timer）的超时时间
默认的 ~20 分钟超时周期对于 DGX Spark 这类开发平台来说过长。可以通过以下方法将超时时间缩短（例如改为 3 分钟），使死锁发生时系统能更快自动恢复。
以下方法 A/B/C 均可通过 SSH 远程执行，无需连接显示器；方法 D（BIOS）需要在 DGX Spark 连接显示器和键盘时操作。对于已切换到无头模式的用户，推荐使用方法 A 通过 SSH 配置。
方法 A：通过 systemd 配置（推荐，SSH 或本地终端均可）
systemd 内置了硬件看门狗的"喂狗"机制。通过设置 RuntimeWatchdogSec，systemd 会以该值的一半为间隔定期喂狗。如果 systemd 本身卡死无法喂狗，「硬件看门狗」（Watchdog Timer）将在设定的超时时间后触发硬件复位。
\# 编辑 systemd 配置文件
sudo nano /etc/systemd/system.conf
\# 找到 #RuntimeWatchdogSec=0 这一行，去掉注释并修改为：
RuntimeWatchdogSec=3min
\# 保存退出后重载 systemd 配置
sudo systemctl daemon-reload
\# 验证配置是否生效
sudo systemctl show -p RuntimeWatchdogSec
\# 预期输出：RuntimeWatchdogSec=3min
设置 RuntimeWatchdogSec=3min 后，systemd 每约 90 秒喂狗一次。如果系统死锁导致 systemd 无法喂狗，3 分钟后「硬件看门狗」（Watchdog Timer）将触发硬件复位，自动重启系统。
方法 B：通过 wdctl 命令临时修改（立即生效，重启后失效）
\# 查看当前超时时间
sudo wdctl
\# 设置超时时间为 180 秒（3 分钟）
sudo wdctl -s 180
\# 验证
sudo wdctl
\# 应显示 Timeout: 180 seconds
注意：此方法仅对当前运行时生效，系统重启后会恢复为默认值。如需永久生效，请使用方法 A 或方法 C。
方法 C：通过内核模块参数（永久生效）
在加载 sbsa_gwdt 模块时指定 timeout 参数：
\# 临时加载（立即生效，重启后失效）
sudo modprobe sbsa_gwdt timeout=180
\# 永久生效：创建模块配置文件
echo "options sbsa_gwdt timeout=180" | sudo tee /etc/modprobe.d/sbsa_gwdt.conf
\# 更新 initramfs
sudo update-initramfs -u -k all
方法 D：通过 BIOS 设置
DGX Spark 的 BIOS 中提供了看门狗开关：
开机时进入 BIOS（按 Del 或 F2，具体按键参考屏幕提示）
进入 Advanced → Watchdog Timer
可选择启用/禁用看门狗，或调整超时参数
注意：BIOS 中的可调选项取决于固件版本，部分版本可能仅提供启用/禁用开关，不提供超时时间调整。如需精确控制超时时间，建议使用方法 A。
5.6 注意事项
将超时时间设得过短（如低于 1 分钟）可能导致系统在正常高负载时误触发复位。建议设置为 3~5 分钟，兼顾死锁恢复速度和正常运行稳定性。
systemd 的 RuntimeWatchdogSec 依赖硬件看门狗设备存在（/dev/watchdog0）且 sbsa_gwdt 模块已加载。如果模块未加载，请先执行：sudo modprobe sbsa_gwdt
在切换到无头模式（multi-user.target）之前配置好看门狗，可以确保即使无人值守，系统死锁后也能自动恢复。
参考资料：
Linux 内核源码 sbsa_gwdt.c： linux/drivers/watchdog/sbsa_gwdt.c at master · torvalds/linux · GitHub
NVIDIA 开发者论坛看门狗讨论： https://forums.developer.nvidia.com/t/crashing-every-few-minutes/360564
GB10 安装指南（sbsa_gwdt 黑名单修复）： ubuntu-gb10/docs/01-ubuntu-install.md at main · timothystewart6/ubuntu-gb10 · GitHub
systemd RuntimeWatchdogSec 官方文档： https://manpages.debian.org/trixie/systemd/systemd-system.conf.5.en.html
六、当前采取的预防措施
1. 关机前手动停止 nvidia-persistenced（最重要）
每次关机或重启前执行：
sudo systemctl stop nvidia-persistenced
ps aux | grep nvidia-persistenced | grep -v grep # 确认已停止
sudo poweroff # 或 sudo reboot
原理：nvidia-persistenced 是死锁的主角——它在关机时调用 nvkms_close 走入死锁路径。提前停止它就不会走到那条死路。这条命令不卸载驱动、不修改内核、不需要重装、完全可逆、零风险。唯一副作用是第一个 CUDA 程序启动慢几百毫秒（GPU 需要重新初始化），完全无感知。
我也创建了 systemd 关机钩子自动执行此操作：/etc/systemd/system/stop-nvidia-persist-before-shutdown.service。该服务只在关机/重启时触发 ExecStop，开机时不做任何事，幂等无副作用。
2. 遇到黑屏时等待 30 秒再操作
上次故障的直接诱因之一是看到黑屏后立即短按电源键触发关机，而此时 X server 刚启动、NVIDIA 驱动正在初始化 modeset，关机恰好撞上了 close 死锁路径。如果再遇到黑屏，等至少 30 秒让驱动初始化完成或自己失败回退，再触发关机。
3. 关机前确认 GPU 进程归零
nvidia-smi # 确认 No running processes found 再关机
4. 启用「硬件看门狗」（Watchdog Timer）的 systemd 喂狗机制
按第五节方法 A 配置 RuntimeWatchdogSec=3min，确保即使发生死锁，系统也能在 3 分钟后自动复位恢复，而非无限期卡死等待人工干预。此配置可通过 SSH 远程完成，无需连接显示器。
5. 考虑切换到无头模式（multi-user.target）
帖子 #371009 的报告者在 DGX Spark 上验证了禁用 GDM/Xorg 切换到 multi-user.target 可避免此 bug。X server 不启动就不会触发 nvkms_close 死锁路径，CUDA/NCCL/Docker 等 GPU 计算工作负载完全不受影响。我主要通过 SSH 使用这台机器，正在考虑这个方案。
七、环境信息
硬件：NVIDIA DGX Spark (GB10, aarch64)
系统：Ubuntu 24.04 LTS
内核：6.11.0-1016-nvidia
驱动：NVIDIA 580.95.05 Open Kernel Module for aarch64
桌面：GNOME on Xorg
本次 boot 启动耗时 1 分 37 秒（firmware 1 分 12 秒，UEFI POST 慢，DGX Spark 固件特性；userspace 15.7 秒，正常）
journal 已持久化（/var/log/journal/ 存在）
内核 cmdline 已有 console=ttyS0,921600
八、两条路径的深度分析：无头模式 vs 反复硬关机
面对这个驱动缺陷，用户只有两条路径可选：
A. 切换到无头模式（multi-user.target），彻底消除死锁触发条件
B. 保持图形界面模式，每次硬关机后重新开机继续使用
以下对两条路径做深度影响分析。
路径 A：切换到无头模式（multi-user.target）
原理：开机时不启动 GDM/X server，NVIDIA 驱动不初始化 modeset，nvkms_close 死锁路径根本不存在。
得到什么：100% 消除 nvkms_close 死锁风险
偶发界面卡死和鼠标变慢问题同时消失（不再有 X server 与驱动争用）
系统更稳定，可 7×24 小时长期运行 GPU 计算任务
系统资源开销降低（不启动 GNOME/Mutter/X server，省约 500MB-1GB 内存）
关机干净利落，SSH 里 sudo poweroff 即可，无死锁风险
失去什么：DGX Spark 直连显示器看不到桌面，所有图形化操作转移到另一台电脑
需要一台笔记本电脑（或台式机）作为操作终端
部分 GUI-only 软件无法在 DGX Spark 上运行（需迁移到笔记本，详见第九节）
初始迁移需要一定工作量：配置 SSH、端口转发、远程文件编辑
长期风险：无。无头模式是 Linux 服务器的标准运行方式，GPU 计算集群普遍这样运行，不会引入新的稳定性问题。
路径 B：保持图形界面，反复硬关机
原理：保持现状，死锁发生时长按电源键硬关机，重新开机。
得到什么：不需要改变使用习惯，继续用图形界面
不需要配置远程访问
不需要迁移任何软件
失去什么（逐项递进）：每次死锁后硬关机，工作流被中断，可能丢失未保存的数据
硬关机时文件系统正在写入的日志、缓存、数据库可能损坏：journal 损坏会导致后续无法追溯故障；ComfyUI 的 sqlite 数据库（/tmp/comfyui_*.db）可能写坏；conda 环境的包缓存可能不一致
反复异常断电对 SSD/eMMC 闪存芯片有物理损耗
偶发界面卡死（Win 键恢复）说明驱动 stall 是间歇性发生的，运行时间越长，某次 stall 恰好命中死锁路径的概率越高
死锁不一定只在关机时触发——X server 异常重启、用户注销、屏幕保护触发 DRM 状态切换都可能走 nvkms_close 路径
运行中的工作流可能在没有任何预兆的情况下被中断
长期风险：文件系统损坏累积：每次硬关机都在赌运气，虽然 ext4 有 journal 保护，但 journal 本身也可能在异常断电时损坏。一旦根文件系统损坏，系统就无法启动，需要从 Live USB 修复或重装系统。
UEFI/固件损坏（低概率但最严重）：异常断电如果恰好赶上 UEFI 固件写入窗口，可能导致 BIOS 损坏，主板变砖，这不是软件能修复的，需要返厂。
存储寿命缩短：闪存芯片的写入寿命有限，异常断电会加速坏块产生。
两条路径对比：
| 维度 | 路径 A（无头模式） | 路径 B（反复硬关机） |
| — | — | — |
| 死锁风险 | 0% | 不可控，概率随运行时间增加 |
| 数据安全 | 高（正常关机） | 低（异常断电可能损坏文件系统） |
| 长期运行稳定性 | 7×24 安全 | 无法保证，随时可能中断 |
| 前期工作量 | 中等（配置远程访问） | 零 |
| 日常使用便利性 | 需通过 SSH/Web UI 操作 | 图形界面直接操作 |
| 硬件损耗 | 正常 | SSD 寿命加速损耗 |
| 最坏情况 | 需要临时切回图形界面 | 文件系统损坏/固件损坏需返厂 |
结论：路径 A 是唯一能 100% 消除风险的方案。路径 B 只能作为在完成路径 A 迁移之前的临时过渡，不应长期持续。
九、无头模式完整迁移方案——AI 工具分类与部署架构
切换到无头模式后，DGX Spark 变成纯粹的 GPU 算力后端。所有软件需要重新分类：哪些留在 DGX Spark 上跑，哪些迁移到笔记本电脑上跑。以下按软件类型逐一分析。
9.1 核心架构
┌──────────────────────────────────────────┐
│ 笔记本电脑（前台 + 协调层） │
│ │
│ \[前台 GUI 软件\] │
│ ├─ 浏览器（访问所有 Web UI） │
│ ├─ VS Code / Trae（Remote-SSH 编辑文件） │
│ ├─ Hermes Agent 跨境电商自动化 │
│ ├─ Obsidian 笔记数据库 │
│ ├─ 代理/VPN 客户端 │
│ ├─ 通讯工具（QQ / 邮箱 / WhatsApp） │
│ └─ 设计/剪辑/办公软件 │
│ │
│ \[协调层\] │
│ ├─ SSH 终端（发指令到 DGX Spark） │
│ ├─ SSH 端口转发（访问 Web UI） │
│ └─ 本地调度脚本 │
└──────────┬───────────────────────────────┘
│ SSH / 局域网
│
┌──────────▼───────────────────────────────┐
│ DGX Spark（纯算力后端） │
│ │
│ \[GPU 计算服务\] │
│ ├─ ComfyUI (port 8188) │
│ ├─ Ollama (port 11434) │
│ ├─ vLLM (port 8000) │
│ ├─ Open WebUI (port 3000) │
│ ├─ Jupyter Lab (port 8888) │
│ └─ 自定义训练/推理脚本 │
│ │
│ \[无头模式运行\] │
│ ├─ multi-user.target │
│ ├─ 无 X server / 无 GDM │
│ ├─ SSH 自动启动 │
│ └─ 100% 无死锁风险 │
└──────────────────────────────────────────┘
核心原则：DGX Spark 只跑需要 GPU 算力的后台服务，所有需要人机交互的前台软件迁移到笔记本。
9.2 三类软件分类与处理
第一类：有 Web UI 的 GPU 工具——留在 DGX Spark 上运行
这类工具的特点是在 DGX Spark 上通过命令行启动后台服务，然后在笔记本浏览器上通过 SSH 端口转发访问 Web 界面。GPU 算力在 DGX Spark 上，界面在笔记本浏览器里显示。
ComfyUI（AI 绘图工作流引擎）
启动：cd /path/to/ComfyUI && python main.py --listen 0.0.0.0 --port 8188
访问：ssh -L 8188:localhost:8188 用户名@IP，浏览器打开 localhost:8188
日志：python main.py --listen 0.0.0.0 --port 8188 2>&1 | tee ~/comfyui.log
然后另开一个 SSH 窗口：tail -f \~/comfyui.log
影响：完全不受无头模式影响，使用体验与有显示器时一致。
Ollama（本地 LLM 运行引擎）
启动：ollama serve（或 sudo systemctl start ollama）
访问：ssh -L 11434:localhost:11434 用户名@IP
API 调用：curl http://localhost:11434/api/generate -d ‘{“model”:“llama3”,“prompt”:“hello”}’
影响：纯命令行/REST API 工具，不依赖图形界面，完全不受影响。
Open WebUI（类似 ChatGPT 的本地 Web 界面）
启动：docker run -d -p 3000:8080 --add-host=host:internal ghcr.io/open-webui/open-webui:main
访问：ssh -L 3000:localhost:3000 用户名@IP，浏览器打开 localhost:3000
影响：Web 界面通过浏览器访问，完全不受无头模式影响。
vLLM（高性能 LLM 推理引擎，兼容 OpenAI API）
启动：python -m vllm.entrypoints.openai.api_server --model meta-llama/Llama-3-8B --port 8000
访问：ssh -L 8000:localhost:8000 用户名@IP
影响：纯 API 服务，不依赖图形界面，完全不受影响。
Jupyter Lab（交互式 Python 开发环境）
启动：jupyter lab --no-browser --port=8888 --ip=0.0.0.0
访问：ssh -L 8888:localhost:8888 用户名@IP，浏览器打开 localhost:8888
影响：Web 界面通过浏览器访问，GPU 加速的 notebook 在 DGX Spark 上运行。
TensorBoard（训练可视化）
启动：tensorboard --logdir=/path/to/logs --port=6006
访问：ssh -L 6006:localhost:6006 用户名@IP，浏览器打开 localhost:6006
影响：Web 界面，完全不受影响。
多个工具同时使用时，一条 SSH 命令转发所有端口：
ssh -L 8188:localhost:8188 \\
-L 11434:localhost:11434 \\
-L 3000:localhost:3000 \\
-L 8888:localhost:8888 \\
用户名@DGX-Spark的IP
结论：所有有 Web UI 的 GPU 工具完全不受无头模式影响，使用体验与有显示器时一致，只是界面从本地浏览器变成通过 SSH 端口转发在笔记本浏览器上显示。
第二类：前台桌面软件（GUI-only，无 Web UI）——迁移到笔记本电脑
这类软件必须有图形界面才能操作，没有 Web 界面，无法通过 SSH 命令行使用，必须迁移到笔记本电脑上运行。
9.2.1 AI 自动化与 SaaS 工具
Hermes Agent 跨境电商自动化（选品分析、Listing 优化、竞品监控、客户跟进、库存预警，核心工具包括 WhatsApp、Email、Skills Hub、Web Tools、Cron、MCP）
部署位置：笔记本电脑
原因：前台 AI Agent 工具，需要浏览器交互、WhatsApp 通信、邮件操作等 GUI 行为，不需要 DGX Spark 的 GPU 算力（调用云端 API，不是本地模型）
迁移方式：在笔记本上安装完整运行环境即可
影响：不会影响 DGX Spark 上任何项目的运行
9.2.2 知识管理与笔记工具
Obsidian（笔记数据库）
部署位置：笔记本电脑
原因：本地 Markdown 编辑器，不依赖 GPU，迁移到笔记本零成本
方式 A（推荐）：在笔记本上安装 Obsidian，用 Syncthing 或 SCP 复制笔记：scp -r 用户名@IP:~/notes ~/notes
方式 B：通过 VS Code Remote-SSH 在笔记本上直接编辑 DGX Spark 上的 .md 文件
方式 C：笔记本装 Obsidian + Syncthing，两台机器自动同步笔记，双向一致
Notion AI / NotebookLM：纯 Web 应用，通过笔记本浏览器访问，不受影响。
9.2.3 设计与创意软件
Midjourney：笔记本浏览器（Discord 或官网），云端渲染。如需本地 AI 绘图，用 DGX Spark 上的 ComfyUI，通过 Web UI 操作。
Canva：笔记本浏览器，纯 Web 应用
Figma：笔记本桌面客户端或浏览器，纯前台工具
9.2.4 视频剪辑与转场工具
HeyGen / Synthesia：笔记本浏览器，云端渲染 SaaS
Runway / Pika Labs / Kling：笔记本浏览器，云端渲染
Descript / Opus Clip：笔记本桌面客户端，前台 GUI 软件。如需 GPU 转码可用 DGX Spark 命令行：ffmpeg -i input.mp4 -c:v h264_nvenc -preset p4 output.mp4
Adobe Premiere / DaVinci Resolve：笔记本电脑，前台 GUI 软件。DaVinci 可通过命令行触发渲染引擎：/opt/resolve/bin/resolve --render project.drp --output output.mp4
9.2.5 CAD 绘图与 3D 建模
AutoCAD / SolidWorks / Fusion 360：笔记本电脑，必须图形界面操作，不支持无头运行
Blender（建模）：笔记本安装 GUI 客户端用于建模操作；Blender（渲染）：DGX Spark 用于 GPU 加速渲染，命令行无头渲染：blender -b scene.blend -o output_ -f 1 – --cycles-device OPTIX
9.2.6 办公自动化与效率工具
Gamma：笔记本浏览器，纯 Web 应用（PPT 生成）
Grammarly：笔记本浏览器插件，写作优化
Superhuman：笔记本桌面客户端，高效邮件
Granola：笔记本桌面客户端，会议记录，需要录音和 GUI 交互
Wispr Flow：笔记本桌面客户端，语音输入，需要本地麦克风和 GUI
9.2.7 开发工具
Cursor / VS Code / Trae：笔记本电脑，通过 Remote-SSH 连接 DGX Spark，在笔记本 IDE 里直接浏览和编辑 DGX Spark 上的代码文件。安装 Remote-SSH 扩展 → 连接 ssh 用户名@IP → 打开项目文件夹。
Replit / Lovable / Base44：笔记本浏览器，纯 Web 应用，云端运行
9.2.8 自动化与集成工具
Zapier / Lindy AI：笔记本浏览器（云端 SaaS）
n8n：可部署在 DGX Spark 上（Docker 容器，有 Web UI），通过端口转发访问：docker run -d -p 5678:5678 n8nio/n8n，ssh -L 5678:localhost:5678 用户名@IP
Chatbase：笔记本浏览器，纯 Web SaaS
Apify / Clay：Apify 可通过 Docker 部署在 DGX Spark 上，无头运行爬虫，不需要图形界面
9.2.9 通讯与代理工具
VPN / 代理客户端：笔记本电脑，代理软件需要 GUI 选择节点。笔记本运行代理做成本地代理服务器，DGX Spark 通过环境变量走笔记本代理：export http_proxy=http://笔记本IP:代理端口
QQ / WhatsApp / 邮箱客户端：笔记本电脑，前台通讯工具，需要 GUI 交互
9.3 文件与日志的远程访问方案
9.3.1 日志远程查看
\# 方式 A：启动时重定向到文件，另开 SSH 窗口用 tail -f 实时查看
python main.py 2>&1 | tee \~/comfyui.log
\# 另一个 SSH 窗口：tail -f \~/comfyui.log
\# 方式 B：用 journalctl 查看系统级日志
journalctl -u comfyui -f # 如果配了 systemd 服务
journalctl -b 0 | grep -i "nvidia\\|error"
9.3.2 文件远程编辑
不需要记住文件绝对路径。使用 VS Code / Trae 的 Remote-SSH：
笔记本上安装 VS Code 或 Trae
安装 Remote-SSH 扩展
连接 ssh 用户名@DGX-Spark的IP
连接后可以看到 DGX Spark 的完整文件树（可视化文件夹结构）
点击打开任意文件编辑，就像在本地操作一样
内置终端可以直接跑命令
9.3.3 文件传输
\# 从 DGX Spark 下载文件到笔记本
scp 用户名@IP:/path/to/file \~/Downloads/
\# 从笔记本上传文件到 DGX Spark
scp \~/file.txt 用户名@IP:/path/to/
\# 传输整个目录
scp -r 用户名@IP:/path/to/dir \~/local-dir/
\# 使用 WinSCP（Windows）或 Cyberduck（macOS）做可视化拖拽传输
9.4 哪些 AI 工具不受影响、哪些需要迁移——完整对照表
| 工具 | 类型 | 部署位置 | 原因 |
| — | — | — | — |
| ComfyUI | GPU + Web UI | DGX Spark | GPU 算力，Web UI 端口转发 |
| Ollama | GPU + API | DGX Spark | GPU 算力，REST API |
| vLLM | GPU + API | DGX Spark | GPU 算力，REST API |
| Open WebUI | Web UI | DGX Spark | Docker，Web 界面端口转发 |
| Jupyter Lab | GPU + Web UI | DGX Spark | GPU 加速 notebook，Web 界面 |
| TensorBoard | Web UI | DGX Spark | 训练可视化，Web 界面 |
| n8n | Web UI | DGX Spark | Docker，Web 界面端口转发 |
| Apify | CLI | DGX Spark | 无头爬虫，命令行运行 |
| Claude / Perplexity | 前台 Web | 笔记本浏览器 | 云端 API，不需要本地 GPU |
| Hermes Agent | 前台 GUI | 笔记本 | AI Agent，调用云端 API |
| Cursor / VS Code / Trae | 前台 IDE | 笔记本 | Remote-SSH 编辑远程文件 |
| Obsidian | 前台 GUI | 笔记本 | 本地 Markdown 编辑器 |
| Midjourney | 前台 Web | 笔记本浏览器 | 云端渲染 |
| HeyGen / Synthesia | 前台 Web | 笔记本浏览器 | 云端渲染 |
| Runway / Pika / Kling | 前台 Web | 笔记本浏览器 | 云端渲染 |
| Descript / Opus Clip | 前台 GUI | 笔记本 | 视频剪辑需要 GUI |
| Canva / Figma | 前台 GUI/Web | 笔记本 | 设计工具 |
| Gamma | 前台 Web | 笔记本浏览器 | PPT 生成 |
| Grammarly | 前台插件 | 笔记本浏览器 | 写作优化 |
| Superhuman / Granola | 前台 GUI | 笔记本 | 邮件/会议工具 |
| Wispr Flow | 前台 GUI | 笔记本 | 语音输入需要本地麦克风 |
| Blender（建模） | 前台 GUI | 笔记本 | 3D 建模需要 GUI |
| Blender（渲染） | GPU + CLI | DGX Spark | 无头渲染 --cycles-device OPTIX |
| Premiere / DaVinci | 前台 GUI | 笔记本 | 视频剪辑需要 GUI |
| AutoCAD / SolidWorks | 前台 GUI | 笔记本 | CAD 需要图形界面 |
| Zapier / Lindy AI | 前台 Web | 笔记本浏览器 | 云端 SaaS |
| Chatbase | 前台 Web | 笔记本浏览器 | 云端 SaaS |
| Clay | 前台 Web | 笔记本浏览器 | 云端 SaaS |
| VPN / 代理 | 前台 GUI | 笔记本 | 需要选择节点 |
| QQ / WhatsApp / 邮箱 | 前台 GUI | 笔记本 | 通讯工具 |
结论：前台 AI 工具的共同特点是——它们依赖云端 API 或本地 CPU，不需要 DGX Spark 的 GPU 算力，迁移到笔记本上零损失。而需要 GPU 算力的工具（ComfyUI、Ollama、vLLM、Blender 渲染）都有 Web UI 或命令行接口，在无头模式下完全不受影响。
9.5 切换到无头模式的具体操作步骤
准备工作（在图形界面模式下完成）
在笔记本上测试 SSH 连接：ssh 用户名@DGX-Spark的IP
在笔记本上安装 VS Code / Trae + Remote-SSH 扩展
测试通过 SSH 端口转发访问 ComfyUI / Ollama 的 Web UI
测试 VS Code Remote-SSH 浏览 DGX Spark 文件树
将笔记、前台软件迁移到笔记本
正式切换
sudo systemctl set-default multi-user.target
sudo reboot
验证
\# 从笔记本 SSH 连接
ssh 用户名@DGX-Spark的IP
\# 确认 GPU 正常
nvidia-smi
\# 确认 CUDA 正常
python -c "import torch; print(torch.cuda.is_available())"
\# 启动需要的工具，端口转发访问
需要临时回到图形界面
sudo systemctl set-default graphical.target
sudo reboot
日常使用流程
开机：按一下电源键，SSH 连进去
用工具：SSH 启动服务 + 端口转发 + 笔记本浏览器访问
编辑文件：VS Code Remote-SSH
关机：SSH 里 sudo poweroff（无死锁风险，直接关）
7×24 运行：完全安全
十、期望
希望 NVIDIA 官方能正式确认并修复 nvkms_close 中的信号量死锁问题。当前 580 系列多个版本都存在此缺陷，而最新的 580.173.02 又有回归 bug 导致 GPU 不可用，DGX Spark 用户陷入了"不升级有死锁风险、升级有 GPU 不可用风险"的两难境地。
由于 Blackwell 架构（包括 GB10）只能使用 Open Kernel Module，NVIDIA 不再提供闭源驱动，用户无法通过切换到闭源驱动来绕过此问题。这使得该 bug 对 DGX Spark 用户的影响更为深远。
建议至少将 nvkms_close 中的 down() 改为可中断或带超时的版本，让 SIGKILL 能在死锁发生时至少释放用户态进程，避免必须硬关机。同时建议在系统层面启用「硬件看门狗」（Watchdog Timer）的 systemd 喂狗机制（RuntimeWatchdogSec），并将默认超时时间从 ~20 分钟缩短至 3~5 分钟，使死锁发生时系统能在可预期的短时间内自动重启，而不是无限期卡死需要人工干预。详见第五节。
==============================================================================
使用过程中界面卡死现象与日志分析（频率更高）
一、遇到的问题
在撰写上述报告的过程中，复制完一个链接后，屏幕突然出现卡死现象——画面完全不动，鼠标和键盘无响应。这是在使用过程中发生的卡死（不是开机时），与报告第一节第 2 点描述的"偶发界面卡死"症状完全一致。按一下 Win 键再按一下，界面恢复正常，继续操作。
二、检测命令与日志原文
故障发生后立即通过 SSH 执行以下检测命令，时间约 18:14（故障发生后 1~2 分钟内）：
# 1. 检查 journalctl 近 10 分钟内 NVIDIA / 内核相关错误
journalctl -b 0 --since "10 min ago" --no-pager | grep -iE "nvidia|nvrm|hung|stall|freeze|block|deadlock|D state|soft lockup|Xid|nvkms"
# 结果：空（无任何输出）
# 2. 检查 journalctl 近 10 分钟内 error 级别日志
journalctl -b 0 --since "10 min ago" --priority=err --no-pager
# 结果：-- No entries --
# 3. 检查 journalctl 近 10 分钟内 warning 级别日志
journalctl -b 0 --since "10 min ago" --priority=warning --no-pager
# 结果：-- No entries --
# 4. 检查 dmesg 中 NVIDIA / GPU / DRM 相关消息
dmesg -T | grep -iE "nvidia|nvrm|gpu|drm|modeset|hung|stall|block"
# 结果：空（无任何输出）
# 5. 检查 Mutter / GNOME 合成器日志
journalctl -b 0 --since "15 min ago" --no-pager | grep -iE "mutter|gnome|gdm|xorg|drm|compositor|render|gl|egl"
# 结果：空（无任何输出）
# 6. 检查 GPU 计算进程
nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv
# 结果：空（无任何 GPU 计算进程）
# 7. 检查 GPU 温度 / 功耗 / 时钟 / 利用率
nvidia-smi --query-gpu=temperature.gpu,power.draw,clocks.sm,clocks.mem,utilization.gpu --format=csv
# 结果：50, 8.68 W, 676 MHz, [N/A], 6 %
# 8. 检查 journalctl 近 15 分钟全部日志
journalctl -b 0 --since "15 min ago" --no-pager
# 结果：仅有 Trae IDE 网络请求、systemd-resolved 时钟同步、sysstat-collect 等常规活动，无任何异常
三、检测结果
| 检测项 | 结果 |
|---|---|
| journalctl NVIDIA/hung/stall 关键字 | 无匹配 |
| journalctl error 级别 | 无条目 |
| journalctl warning 级别 | 无条目 |
| dmesg NVIDIA/GPU/DRM | 无匹配 |
| Mutter/GNOME 合成器日志 | 无匹配 |
| GPU 计算进程 | 无（完全空闲） |
| GPU 温度 | 50°C（正常空闲） |
| GPU 功耗 | 8.68W（低功耗空闲） |
| GPU 利用率 | 6%（空闲） |
所有日志干干净净，没有任何错误、警告或异常事件。
四、如何判断为同一个问题
日志里什么都没有，恰恰是判断的关键依据。
-
症状完全吻合
本次卡死的特征——画面完全不动、鼠标键盘无响应、按 Win 键后恢复——与报告第一节第 2 点描述的"偶发界面卡死"症状完全一致。 -
排除其他原因
- GPU 过载？GPU 利用率 6%、温度 50°C、无计算进程——完全空闲，排除。
- 内存不足？无 OOM-kill 记录，排除。
- CPU 过载？无高负载进程，排除。
- 网络问题？仅 Trae IDE 常规网络请求，排除。
- 文件系统错误？无 I/O error，排除。
-
日志空白本身就是证据
如果卡死是由内核级死锁引起，日志中会出现 hung task 警告（进程 D 状态超过 120 秒）。如果 GPU 硬件错误，会产生 Xid 事件。两者都没有，说明卡死不是永久性的内核死锁，而是 NVIDIA 驱动在中断上下文中的瞬时 stall（信号量竞争或 GPU 渲染管线短暂卡顿）。 -
机制解释
GNOME 桌面的合成器 Mutter 依赖 GPU 进行画面合成。NVIDIA 驱动在内部中断处理中做过多工作时，会导致内核调度延迟（DPC latency）飙升，Mutter 等待 GPU 渲染管线返回结果，画面冻结。由于 stall 是瞬时的（几秒内自恢复），不会触发内核看门狗（hung task 需要 120 秒），也不会产生 GPU 硬件错误（Xid），所以日志中不留任何痕迹。按 Win 键触发 GNOME Shell 重新绘制 Activities 概览，相当于给 Mutter 发送强制重绘信号——此时 stall 已恢复，画面就能正常重绘。 -
与开机黑屏死锁的关系
两者根因相同（NVIDIA 580.95.05 Open Kernel Module 在 GB10 上的驱动缺陷），但严重程度不同：
- 开机黑屏死锁 = stall 永久不恢复（信号量死锁）→ hung task 警告 → 必须硬关机
- 使用中界面卡死 = stall 瞬时自恢复 → 无日志 → Win 键恢复
五、无头模式能否解决此卡顿
可以，且是彻底解决。
切换到无头模式（multi-user.target）后：
- 开机不启动 GDM / X server → 不启动 Mutter 合成器 → 不依赖 GPU 进行画面合成
- NVIDIA 驱动的间歇性 stall 仍然存在（驱动缺陷未修复），但没有人依赖 GPU 渲染管线做画面合成，所以 stall 不会表现为可见的界面冻结
- GPU 计算工作负载（CUDA / NCCL / Docker）走的是 compute 路径，不经过 modeset/render 路径，不受此 stall 影响
- SSH 终端由 CPU 处理，与 GPU 无关，不会卡顿
按 Win 键恢复的原因：stall 是瞬时的，按 Win 键触发重绘时 stall 已经自行恢复。如果 stall 是永久性死锁（如开机黑屏），按 Win 键不会有任何效果。能通过 Win 键恢复本身就证明 stall 是瞬时的。
结论：无头模式是唯一能 100% 消除此界面卡顿的方案。在切换到无头模式之前，遇到卡死时按 Win 键即可恢复，不影响数据安全。