title: 4090 工作站软件维修记录
slug: 4090-workstation-repair4090 工作站软件维修记录
背景
研究院有一台4090工作站一直在吃灰，说是系统坏掉了，但是一直没人有精力去抽空修。在征得同意后我打算尝试维修下。
工作站配置不错，ASUS W680 主板，i9 处理器，128GB 内存，RTX 4090 24G，2TB NVMe 固态。机器前面插着一个 U 盘，后面确认是个Ubuntu 20.04的安装盘。
想法很简单：先确认能不能开机，能不能出画面，能不能进系统。不行再考虑重装。
按电源，风扇转了，灯亮了。显示器没反应，直接进了待机。
检查视频输出
先检查机箱背面线接没接。这台主机背后有两组视频口——上面是主板的 DP 和 HDMI，下面才是 RTX 4090 的独显输出。显示器线之前插在了上面。
把线换到下面 4090 的 DP 口，显示器手动切到 DP 输入。ASUS 的 logo 出来了，接着出现了 Ubuntu 的启动画面。
这是第一个进展。机器不是完全坏的，显卡至少能输出基础画面。
尝试安装Ubuntu 20.04
Ubuntu 启动画面闪过之后，屏幕黑了。
不是完全死机——NumLock 键盘灯有反应，Ctrl + Alt + Delete 能重启。但 Ctrl + Alt + F3 切 TTY 切不过去。系统卡在了从启动画面到图形桌面的中间地带。
想进 GRUB 改启动参数，加个 nomodeset 绕开图形界面试试。但手上的时机老是不对——按 Esc 太猛进了 grub> 命令行，输 normal 跳回去又黑屏，再按又进了 BIOS。折腾了几轮，始终没能稳定进入 GRUB 菜单。
感觉是硬盘里面的系统坏掉了，用上面插着的安装盘试试。
进 UEFI 调启动顺序。U 盘和内部 2TB NVMe 都能识别，硬盘没坏。
从 U 盘启动，先进 Try Ubuntu 看了一眼——lsblk 能看到 1.8T 的 NVMe，lspci 能看到 NVIDIA 设备。硬件都在。
机器上贴着资产管理标签：用户名 ubuntu，密码 1。问了下同事，说原系统数据不要了，于是准备清盘。安装时保留了原来的账号密码，这样以后别人按贴纸登录不会出问题。
选了 Erase disk and install Ubuntu。安装器开始创建 ext4 文件系统，然后不动了。
Creating ext4 file system for / in partition #2 of /dev/nvme0n1
等了很久。切 TTY 看了进程和 syslog，确认不是假死。1.8T 的 NVMe 创建 ext4 不该这么慢。可能是 20.04 安装器对这块新主板的兼容问题，那就换 22.04 试试。
尝试Ubuntu 22.04
准备了 Ventoy 启动 22.04 ISO。normal mode 和 grub2 mode 都试了。
进入安装菜单，选了 Safe Graphics——想着用保守的显示参数启动，应该能绕开 4090 显卡驱动导致的黑屏。
但后面还是莫名其妙的卡死。
有时候能进 Live 系统，有时候卡在 snapd 加载 AppArmor。加上 nomodeset、nouveau.modeset=0、systemd.unit=multi-user.target，甚至把 snapd 也 mask 掉，结果卡在另一个地方——dbus、gtk、fuse 附近。
dbus-daemon
org.gtk.vfs.Daemon
fuse: device not found
A connection to the bus can't be made
20.04 和 22.04 的 Desktop 安装器都走不通，Safe Graphics 和各种启动参数组合没一个能稳定把系统装上去。直觉告诉我可能是N卡的显卡驱动问题。
绕路Ubuntu 22.04 Server
Desktop 不行，换 Server。
Server和desktop，本质上用的是同一套 apt 软件源、同一套内核、同一套 glibc、同一套包管理系统。所以对这些东西来说基本没区别：
NVIDIA 驱动
CUDA
cuDNN
PyTorch / TensorFlow
Docker / nvidia-container-toolkit
ROS2 Humble
编译 C++ / Python 环境
Isaac 相关依赖
区别的话，默认软件少一点，网络配置可能不一样，显示管理器和图形栈是后装的（自选）。
最主要的是，Ubuntu Server 22.04 的安装器是文本界面，不需要 GNOME、GDM、Wayland、Xorg 这一整套图形栈。果然安装很顺利——硬盘、网卡、CPU、内存都没问题。
Server 装好之后，第一次看到了一个稳定的命令行界面。装 NVIDIA 驱动，再补装 ubuntu-desktop。重启。桌面出来了，nvidia-smi 能看到 RTX 4090。
看起来修好了。
稳定性问题
后面问题又来了，重启之后又卡死了。
冷启动能进系统，但偶尔启动阶段会卡很久，，甚至出现 CPU soft lockup 和 kernel call trace。运气好开机成功后翻 journalctl，看到：
watchdog: BUG: soft lockup - CPU#4 stuck for 2086s! [systemd-udevd:844]
也就是说，卡住的不是普通桌面程序，而是 systemd-udevd。它负责根据硬件事件加载驱动、创建设备节点、处理设备规则。systemd-udevd 卡住，说明问题很可能发生在硬件枚举 / 内核模块加载 / 设备驱动初始化阶段，而不是简单的桌面服务启动失败。
日志还显示当时系统正在处理内核模块加载路径：
__do_sys_finit_module
load_module
complete_formation
module_enable_ro
并且模块列表里出现了一堆底层模块，其中包含两个比较显眼的名字：
fjes(-)
mfd_aaeon
asus_wmi
完整硬件信息中也能看到，这台机器是：
ASUSTeK COMPUTER INC. E500 G9_WS760T/W680/SYS
BIOS 2101 01/16/2023
日志里明确出现该硬件信息和 5.15.0-179-generic 内核版本。
这时最初的直觉是怀疑 mfd_aaeon。因为它和 ASUS/AAEON 主板 WMI、EC、GPIO、传感器、watchdog 等功能有关，看起来很像主板辅助驱动。但尝试 blacklist mfd_aaeon 后，问题并没有真正解决，说明它最多是"现场出现过的相关模块"，不一定是真凶。
继续看更完整的上一轮启动日志，发现真正更扎眼的是：
Modules linked in: fjes(-) ...
fjes 是一个非常冷门的 Fujitsu Extended Socket Network Device 驱动。对于这台 ASUS W680 + RTX 4090 工作站来说，它几乎没有实际用途。它不像 NVIDIA、NVMe、USB、Intel 网卡这些核心模块；更像是某个通用内核里自带、但在这台机器上不该发挥作用的边缘驱动。
括号里的 - 表示模块正处于卸载或移除状态——正好卡在 udev 处理模块加载/卸载的时候。
因此判断：fjes 很可能是在 udev 枚举硬件或处理模块加载/卸载时触发了内核级卡死。
执行：
echo "blacklist fjes" | sudo tee /etc/modprobe.d/blacklist-fjes.conf
echo "install fjes /bin/false" | sudo tee -a /etc/modprobe.d/blacklist-fjes.conf
sudo update-initramfs -u -k all
sudo update-grub
把 fjes 加入黑名单，重建 initramfs，重启。lsmod | grep fjes 没有输出，那种 udev 软锁死的现象明显缓解了。
不是显卡问题，不是桌面问题，是一个跟这台机器八竿子打不着的冷门内核模块触发了 udev 死锁。
这一步之后，之前那种 systemd-udevd + soft lockup 的严重卡死现象明显减少。后续日志里更多表现为 GDM 启动慢、网络管理混乱、用户态服务拖慢启动，而不是直接内核 soft lockup。
解决启动异常的慢
fjes 禁掉之后，系统从"能不能进看心情"变成了 "您的启动时间已打败全国1%的用户"
后面详细 systemd-analyze 的结果：
Startup finished in 1min 56.606s
graphical.target reached after 1min 35.610s in userspace
BIOS、bootloader、kernel 加起来不到 20 秒，userspace 拖了 1 分 35 秒。gdm.service 一个人占了 1 分 24 秒。
GDM 日志显示：第一次启动前置步骤超时，systemd 自动重启 GDM，第二次才成功。肉眼看到的现象就是开机卡住、等了很久、像是失败了、最后突然进了桌面。
然后做了一圈收敛。
关掉 Wayland，让 GDM 固定走 Xorg。这台 Server 后补 Desktop 的系统里，systemd-networkd 和 NetworkManager 同时 active，enp5s0 在 NetworkManager 里显示 unmanaged。把 netplan 的 renderer 改成 NetworkManager，禁用 networkd 和 wait-online。关掉一堆对工作站没用的东西：SSSD 企业域认证、LXD 容器管理、multipathd 多路径存储。
开机快了，GDM 还是慢，但至少不像之前那样让人以为又挂了。
还有高手
在做完 GDM、网络栈和服务清理后，重启一下电脑：
sudo reboot
屏幕一黑：
Kernel panic - not syncing: Fatal exception in interrupt
内核直接崩溃。
诡异的是，断电冷启动正常。热重启炸，冷启动好。这时已经不能只盯 GDM 或网络服务了。问题再次下沉到内核/固件/硬件兼容层面。
更换内核
问题来到了内核/固件/硬件兼容层面。
这时候系统跑的还是 Ubuntu 22.04 自带的 5.15 GA 内核。5.15 是保守的长期维护版本，但面对 W680 主板、i9、4090 这套新硬件，老内核不一定就更稳。
查了一下，Ubuntu 22.04 有 HWE 内核，版本 6.8，专门给 LTS 系统提供新硬件支持。
基于前面的判断，最终决定安装 HWE：
sudo apt update
sudo apt install -y --install-recommends linux-generic-hwe-22.04 linux-headers-generic-hwe-22.04
sudo update-grub
为了避免再次触发热重启 panic，装完后没有立刻 sudo reboot，而是选择：
sudo poweroff
然后等待完全断电，再手动开机。
冷启动进 6.8 内核，重建 NVIDIA DKMS 模块，nvidia-smi 正常。
再试热重启——通过了。
之后又试了几次冷启动和热重启，都稳住了。这下可以宣告维修成功了。
小结
这次就是典型的洋葱式排障：
外层：Ubuntu Desktop Live / Safe Graphics 卡死
中层：systemd-udevd soft lockup
再往里：fjes 模块异常
继续往里：GDM 启动慢
继续往里：networkd / NetworkManager 混用
继续往里：sudo reboot 热重启 kernel panic
最终指向：5.15 GA 内核和新硬件组合不够稳
修好之后收拾东西，关机。机器安安静静放在那里，跟没出过事一样。