花了大概六个小时彻底解决问题。因为我很久之前就遇到过一样的问题当时我认输了重装系统。但是现在我这个ubuntu有太多东西了我不能失去而且我不想认输第二次。如果遇到类似问题可以按照我的操作方法一条条试。首先根本原因这是 Linux 5.15.0-139 内核与这台 Lenovo Intel 13代平台PCH之间的 PCI/MSI 中断兼容性问题。不是❌ NVIDIA 驱动❌ snapd❌ binfmt_misc❌ initramfs❌ ext4❌ NVMe❌ USB 外设本身❌ Recovery Mode❌ GDM❌ Wayland真正的问题发生在更底层。这台电脑发生过什么5.15.0-139 本身存在一个与这台机器相关的 PCI/MSI 兼容性问题。不过不能确定是哪个设备带来的。这个问题长期潜伏并非每次启动都会暴露。7 月 27 日进入 Windows、进入 BIOS 并不小心修改哪怕改回Graphic Device 后硬件初始化状态发生了变化。7 月 28 日开始139 的 MSI 初始化稳定触发了这个 Bug导致整个系统在根文件系统挂载后失去中断响应。pcinomsi完全绕过了 MSI 路径因此系统恢复正常。为什么grub里linux那一行末尾加入pcinomsi能解决PCI 设备有两种中断方式传统INTx现代MSI或者MSI-XLinux 5.15.0-139 默认大量使用 MSI。机器某个 PCI 设备或者 PCHMSI 有兼容性 Bug。于是设备初始化完成以后等待 MSI 中断↓中断永远收不到↓CPU 一直等待↓整个系统看起来死机。关键逻辑1.Recovery Mode 一样卡。这一下其实已经把GDMWaylandGNOMENVIDIA Desktop基本全排除了。因为 Recovery 根本不会启动这些。2.试了init/bin/bash结果root(none):/#出来了。但是不能输入。NumLock灭。CapsLock没反应。说明不是 shell 没启动。而是CPU已经不响应键盘中断。一、问题概述项目详情设备联想拯救者 Y7000P 2025i7-14650HX RTX 5060 Laptop GPU系统Ubuntu 20.04 LTSHWE 内核正常内核5.15.0-67-generic故障内核5.15.0-139-generic故障时间7.27正常关机后7.28开机突然无法启动。recovery mode都卡。触发因素推测误触 BIOS 设置按 F2 进入 BIOS 后点了一下某个选项又点回来已复原此前执行过sudo apt upgrade二、最初症状2.1 屏幕报错[FAILED] Failed to start Load Kernel Modules. See systemctl status systemd-modules-load.service for details. Failed to load kernel module chromeos-pstore. Failed to start RF Kernel Switch Status.2.2 启动行为5.15.0-67-generic正常启动进入桌面。5.15.0-139-generic卡死无法进入系统。Recovery Mode同样卡死无法进入恢复菜单。2.3 最终卡死画面/dev/nvme0n1p6: clean, 1383058/13107200 files, 47536298/52428800 blocks [ 2.776653] _光标停止闪烁系统完全无响应。三、三方 AI 初始判断第一轮3.1 DeepSeek核心假设systemd-modules-load.service失败是根因。怀疑方向NVIDIA 驱动 Secure Boot 冲突。推理看到systemd-modules-load.service报错联想到 NVIDIA DKMS 模块在 Secure Boot 开启时无法签名加载。建议操作检查/禁用 Secure Boot重装 NVIDIA 驱动更新内核头文件执行sudo dkms autoinstall3.2 ChatGPT核心假设chromeos_pstore是噪音不是根因。怀疑方向snapd或binfmt_misc循环导致卡死。推理注意到chromeos_pstore报错在非 ChromeOS 设备上很常见且不阻塞启动真正的问题可能在 systemd 服务层。建议操作检查 snap 状态snap changes查看 snapd 日志分析/var/log/apt/history.log3.3 Claude核心假设initramfs 内容异常或/boot空间不足。怀疑方向/boot分区空间不足导致 initramfs 截断或模块缺失。推理注意到journalctl --list-boots没有卡死启动的日志硬卡死日志无法落盘怀疑 initramfs 生成不完整。建议操作df -h /bootls -la /boot/initrd.img-*diff对比两个 initramfs 的内容sudo update-initramfs -u -k 5.15.0-139-generic四、第一轮排查4.1 检查 Secure Bootmokutil --sb-state结果Secure Boot 已禁用。三方结论❌ 排除 Secure Boot 问题。4.2 检查 DKMS 状态dkms status结果NVIDIA 模块为5.15.0-139-generic成功编译状态installed。三方结论❌ 排除 NVIDIA DKMS 编译失败。4.3 检查/boot空间df -h /boot ls -la /boot/initrd.img-5.15.0-*结果/boot不是独立分区挂在根分区下空间充足-139initrd92MB比-6780MB还大没有截断。三方结论❌ 排除/boot空间不足或 initramfs 截断。4.4 重新生成 initramfssudo update-initramfs -u -k 5.15.0-139-generic sudo update-grub结果执行成功但问题依旧。三方结论❌ 排除 initramfs 损坏至少不是简单损坏。五、中间阶段systemd 服务层排查5.1 检查 snapd 状态和日志snap changes snap list --all journalctl -u snapd --since 7 days ago结果snapd 在 7 月 27 日有网络错误408 超时、DNS misbehaving但snap changes显示所有任务已完成。DeepSeek 判断snapd 可能有异常建议 mask snapd 验证。ChatGPT 判断同样怀疑 snapd 自动更新可能触发了问题。Claude 判断未直接评论 snapd 方向。5.2 Mask snapd验证 snapd 是否为根因sudo systemctl mask snapd.service snapd.socket snapd.seeded.service结果重启后-139仍然卡死症状完全一样。三方结论❌ 排除 snapd 为根因。5.3 检查 apt 历史grep -E Start-Date|Upgrade:|Install: /var/log/apt/history.log | tail -100 zcat /var/log/apt/history.log.*.gz | grep -i linux-firmware结果7 月 21 日用户安装/卸载了 kazam 等多媒体包。3 月 12 日linux-firmware从1.187.36升级到1.187.39。DeepSeek 初步判断linux-firmware可能是元凶。ChatGPT 判断时间线不吻合——3 月升级7 月才坏排除。a/发力Claude暴死退出。5.4 Mask proc-sys-fs-binfmt_misc.automountsudo systemctl mask proc-sys-fs-binfmt_misc.automount结果重启后-139仍然卡死。结论❌ 排除binfmt_misc挂载为根因。六、关键转折目标层级下移6.1 测试multi-user.target在 GRUB 中在linux行末尾添加systemd.unitmulti-user.target结果仍然卡死。结论❌ 排除图形界面服务。6.2 测试rescue.target在 GRUB 中在linux行末尾添加systemd.unitrescue.target结果仍然卡死。结论❌ 排除multi-user.target特定服务。6.3 测试emergency.target在 GRUB 中在linux行末尾添加systemd.unitemergency.target结果仍然卡死。DeepSeek 判断仍然怀疑binfmt_misc或 snap。ChatGPT 判断开始怀疑问题发生在 systemd 启动之前建议systemd.device_watchdog参数。关键转折点emergency.target是 systemd 最精简的启动模式它只启动sysinit.target中的基础服务。如果它都卡死问题一定在sysinit.target层或更早。6.4 测试systemd.device_watchdog在 GRUB 中在linux行末尾添加systemd.device_watchdog30 systemd.device_watchdog_timeout30结果仍然卡死。deepseek方向无效。七、决定性突破init/bin/bash7.1 ChatGPT 的关键提问“如果init/bin/bash都卡死那问题不在 systemd不在用户态服务而在内核与硬件的交界处。”7.2 执行init/bin/bash在 GRUB 中在linux行末尾添加init/bin/bash启动后屏幕显示bash: cannot set terminal process group (-1): Inappropriate ioctl for device bash: no job control in this shell root(none):/# [USB 枚举日志...]实际状态屏幕显示了root(none):/#提示符。键盘完全无反应按任何键都没有输入回显。Num Lock 灯熄灭CtrlAltDel无反应。这不是“进入了 bash”而是“bash 刚打印出提示符系统就硬锁死了”。7.3 对init/bin/bash结果的解读DeepSeek仍然怀疑是 systemd 某些服务的残留影响或binfmt_misc在 kernel 层面的循环。未充分重视“Num Lock 灯灭”这个信号。继续在 systemd 层面思考。浪费我大量时间。ChatGPT立即识别出这是硬死锁Hard Lockup。指出Num Lock 灯灭意味着 CPU 停止响应中断这是内核/硬件层面的问题。放弃所有 systemd/snap/bin 方向转向APIC/PCI/ACPI/CPU 电源管理。建议测试底层参数noapic、irqpoll、pcinomsi、intel_idle.max_cstate0。八、最重要底层参数测试8.1noapic irqpoll在 GRUB 中在linux行末尾添加noapic irqpoll结果仍然卡死。结论❌ APIC 中断方向不是根因。8.2intel_idle.max_cstate0 processor.max_cstate1在 GRUB 中在linux行末尾添加intel_idle.max_cstate0 processor.max_cstate1结果仍然卡死。结论❌ CPU 电源管理 C-State 不是根因。8.3pcinomsi✅在 GRUB 中在linux行末尾添加pcinomsi结果成功进入系统结论✅ MSI消息信号中断是根本原因。九、pcinomsi的含义与后续验证9.1 参数说明MSIMessage Signaled Interrupt现代 PCIe 设备使用的中断机制比传统 INTx 更高效。pcinomsi强制内核禁用所有 PCI 设备的 MSI回退到传统 INTx 中断。9.2 验证pcinomsi后系统表现✅ 系统正常启动进入桌面。✅ NVIDIA 驱动正常工作nvidia-smi可用。⚠️ USB 初始化变慢出现xhci_hcd: Timeout while waiting for setup device command。⚠️ 但系统没有卡死USB 超时只是禁用 MSI 后的副作用。9.3 排除其他设备nomodeset无效 → 不是 NVIDIA DRM/KMS拔掉 USB 外设无效 → 不是外设问题NVMe 工作正常nvme0: 1/0/0 queues→ NVMe 不是根因十、pcinomsi的副作用及后续处理10.1 副作用ChatGPT 提供影响严重程度说明PCIe 设备性能略降⭐⭐中断效率降低NVMe SSD⭐连续读写可能下降几个百分点USB 初始化变慢⭐⭐已看到 Timeout 日志网卡/WiFi 高负载⭐⭐CPU 占用可能略高GPU⭐几乎无影响电池续航⭐影响很小10.2 VSCode 无法打开报错内部错误请报告运行 code 失败timeout waiting for snap system profiles to get updated原因之前排查时执行了sudo systemctl mask snapd.service snapd.socket snapd.seeded.service忘记解除屏蔽。解决sudo systemctl unmask snapd.service snapd.socket snapd.seeded.service sudo systemctl start snapd sudo systemctl enable snapd结果VSCode 恢复正常。10.3 永久应用pcinomsisudo nano /etc/default/grub # 修改 GRUB_CMDLINE_LINUX_DEFAULTquiet splash pcinomsi sudo update-grub10.4 可选锁定稳定内核sudo apt-mark hold linux-image-5.15.0-67-generic linux-headers-5.15.0-67-generic十一、为什么-67正常而-139坏的最终分析11.1 内核差异5.15.0-672022 年底发布PCIe 中断处理代码较保守。5.15.0-1392024 年后更新包含了 Intel Raptor Lake 平台的 PCIe MSI 优化补丁。11.2 硬件组合Intel Raptor Lake Refreshi7-14650HXIntel 700 系列 PCHMediaTek MT7925 Wi-FiUnion Memory NVMe SSD特定 BIOS 版本S9CN13WW11.3 BIOS 状态变化用户误触 BIOS 设置后按 F2 进入 BIOS 点了一下某个选项又点回来改变了 PCIe 设备的 IRQ 路由方式使得原本隐藏的 MSI 死锁暴露出来。11.4 结论Linux 5.15.0-139 在联想 Y7000P 2025 上某个 PCIe 设备高度怀疑 Intel xHCI USB 控制器启用 MSI 后触发了内核级硬死锁。pcinomsi禁用 MSI回退到传统 INTx绕过了该兼容性问题。十二、后续排查方向ChatGPT 建议如果未来想“精准定位”而不是“一刀切”可以依次测试intel_iommuoff如果有效问题在 IOMMU MSI 组合pcinoaer禁用 PCIe 高级错误报告pcinommconf禁用 MMCONFIG检查联想官网是否有 BIOS 更新十三、命令执行结果汇总表以下是用过的指令遇到相同问题可以参考。序号命令/参数执行结果是否解决问题1mokutil --sb-state✅ 成功❌ 排除2dkms status✅ 成功❌ 排除3df -h /boot✅ 成功❌ 排除4ls -la /boot/initrd.img-*✅ 成功❌ 排除5uname -r✅ 成功确认环境6sudo update-initramfs -u -k 5.15.0-139✅ 成功❌ 无效7snap changes✅ 成功❌ 排除8snap list --all✅ 成功❌ 排除9journalctl -u snapd --since 7 days ago✅ 成功⚠️ 线索10sudo systemctl mask snapd...✅ 成功❌ 无效11grep ... /var/log/apt/history.log✅ 成功⚠️ 线索12zcat ... grep linux-firmware✅ 成功⚠️ 线索13dpkg -l grep linux-firmware✅ 成功⚠️ 线索14sudo systemctl mask proc-sys-fs-binfmt_misc.automount✅ 成功❌ 无效15sudo systemctl unmask snapd...✅ 成功✅ 修复 VSCode16nomodeset(GRUB)❌ 卡死❌ 排除17systemd.unitmulti-user.target(GRUB)❌ 卡死❌ 排除18systemd.unitrescue.target(GRUB)❌ 卡死❌ 排除19systemd.unitemergency.target(GRUB)❌ 卡死❌ 排除20init/bin/bash(GRUB)⚠️ 硬锁死❌ 排除用户态21systemd.debug-shell(GRUB)❌ 无反应❌ 排除22systemd.device_watchdog30(GRUB)❌ 卡死❌ 排除23noapic irqpoll(GRUB)❌ 卡死❌ 排除24intel_idle.max_cstate0 processor.max_cstate1(GRUB)❌ 卡死❌ 排除25pcinomsi(GRUB)✅成功启动✅找到根因26sudo nano /etc/default/grubsudo update-grub✅ 成功✅ 永久修复27sudo apt-mark hold linux-image-5.15.0-67...✅ 成功✅ 双重保险28sudo apt remove linux-image-5.15.0-139...⚠️ 未执行N/A
ubuntu20.04的5.15.139内核启动卡死问题解决过程
发布时间：2026/7/29 4:21:34
花了大概六个小时彻底解决问题。因为我很久之前就遇到过一样的问题当时我认输了重装系统。但是现在我这个ubuntu有太多东西了我不能失去而且我不想认输第二次。如果遇到类似问题可以按照我的操作方法一条条试。首先根本原因这是 Linux 5.15.0-139 内核与这台 Lenovo Intel 13代平台PCH之间的 PCI/MSI 中断兼容性问题。不是❌ NVIDIA 驱动❌ snapd❌ binfmt_misc❌ initramfs❌ ext4❌ NVMe❌ USB 外设本身❌ Recovery Mode❌ GDM❌ Wayland真正的问题发生在更底层。这台电脑发生过什么5.15.0-139 本身存在一个与这台机器相关的 PCI/MSI 兼容性问题。不过不能确定是哪个设备带来的。这个问题长期潜伏并非每次启动都会暴露。7 月 27 日进入 Windows、进入 BIOS 并不小心修改哪怕改回Graphic Device 后硬件初始化状态发生了变化。7 月 28 日开始139 的 MSI 初始化稳定触发了这个 Bug导致整个系统在根文件系统挂载后失去中断响应。pcinomsi完全绕过了 MSI 路径因此系统恢复正常。为什么grub里linux那一行末尾加入pcinomsi能解决PCI 设备有两种中断方式传统INTx现代MSI或者MSI-XLinux 5.15.0-139 默认大量使用 MSI。机器某个 PCI 设备或者 PCHMSI 有兼容性 Bug。于是设备初始化完成以后等待 MSI 中断↓中断永远收不到↓CPU 一直等待↓整个系统看起来死机。关键逻辑1.Recovery Mode 一样卡。这一下其实已经把GDMWaylandGNOMENVIDIA Desktop基本全排除了。因为 Recovery 根本不会启动这些。2.试了init/bin/bash结果root(none):/#出来了。但是不能输入。NumLock灭。CapsLock没反应。说明不是 shell 没启动。而是CPU已经不响应键盘中断。一、问题概述项目详情设备联想拯救者 Y7000P 2025i7-14650HX RTX 5060 Laptop GPU系统Ubuntu 20.04 LTSHWE 内核正常内核5.15.0-67-generic故障内核5.15.0-139-generic故障时间7.27正常关机后7.28开机突然无法启动。recovery mode都卡。触发因素推测误触 BIOS 设置按 F2 进入 BIOS 后点了一下某个选项又点回来已复原此前执行过sudo apt upgrade二、最初症状2.1 屏幕报错[FAILED] Failed to start Load Kernel Modules. See systemctl status systemd-modules-load.service for details. Failed to load kernel module chromeos-pstore. Failed to start RF Kernel Switch Status.2.2 启动行为5.15.0-67-generic正常启动进入桌面。5.15.0-139-generic卡死无法进入系统。Recovery Mode同样卡死无法进入恢复菜单。2.3 最终卡死画面/dev/nvme0n1p6: clean, 1383058/13107200 files, 47536298/52428800 blocks [ 2.776653] _光标停止闪烁系统完全无响应。三、三方 AI 初始判断第一轮3.1 DeepSeek核心假设systemd-modules-load.service失败是根因。怀疑方向NVIDIA 驱动 Secure Boot 冲突。推理看到systemd-modules-load.service报错联想到 NVIDIA DKMS 模块在 Secure Boot 开启时无法签名加载。建议操作检查/禁用 Secure Boot重装 NVIDIA 驱动更新内核头文件执行sudo dkms autoinstall3.2 ChatGPT核心假设chromeos_pstore是噪音不是根因。怀疑方向snapd或binfmt_misc循环导致卡死。推理注意到chromeos_pstore报错在非 ChromeOS 设备上很常见且不阻塞启动真正的问题可能在 systemd 服务层。建议操作检查 snap 状态snap changes查看 snapd 日志分析/var/log/apt/history.log3.3 Claude核心假设initramfs 内容异常或/boot空间不足。怀疑方向/boot分区空间不足导致 initramfs 截断或模块缺失。推理注意到journalctl --list-boots没有卡死启动的日志硬卡死日志无法落盘怀疑 initramfs 生成不完整。建议操作df -h /bootls -la /boot/initrd.img-*diff对比两个 initramfs 的内容sudo update-initramfs -u -k 5.15.0-139-generic四、第一轮排查4.1 检查 Secure Bootmokutil --sb-state结果Secure Boot 已禁用。三方结论❌ 排除 Secure Boot 问题。4.2 检查 DKMS 状态dkms status结果NVIDIA 模块为5.15.0-139-generic成功编译状态installed。三方结论❌ 排除 NVIDIA DKMS 编译失败。4.3 检查/boot空间df -h /boot ls -la /boot/initrd.img-5.15.0-*结果/boot不是独立分区挂在根分区下空间充足-139initrd92MB比-6780MB还大没有截断。三方结论❌ 排除/boot空间不足或 initramfs 截断。4.4 重新生成 initramfssudo update-initramfs -u -k 5.15.0-139-generic sudo update-grub结果执行成功但问题依旧。三方结论❌ 排除 initramfs 损坏至少不是简单损坏。五、中间阶段systemd 服务层排查5.1 检查 snapd 状态和日志snap changes snap list --all journalctl -u snapd --since 7 days ago结果snapd 在 7 月 27 日有网络错误408 超时、DNS misbehaving但snap changes显示所有任务已完成。DeepSeek 判断snapd 可能有异常建议 mask snapd 验证。ChatGPT 判断同样怀疑 snapd 自动更新可能触发了问题。Claude 判断未直接评论 snapd 方向。5.2 Mask snapd验证 snapd 是否为根因sudo systemctl mask snapd.service snapd.socket snapd.seeded.service结果重启后-139仍然卡死症状完全一样。三方结论❌ 排除 snapd 为根因。5.3 检查 apt 历史grep -E Start-Date|Upgrade:|Install: /var/log/apt/history.log | tail -100 zcat /var/log/apt/history.log.*.gz | grep -i linux-firmware结果7 月 21 日用户安装/卸载了 kazam 等多媒体包。3 月 12 日linux-firmware从1.187.36升级到1.187.39。DeepSeek 初步判断linux-firmware可能是元凶。ChatGPT 判断时间线不吻合——3 月升级7 月才坏排除。a/发力Claude暴死退出。5.4 Mask proc-sys-fs-binfmt_misc.automountsudo systemctl mask proc-sys-fs-binfmt_misc.automount结果重启后-139仍然卡死。结论❌ 排除binfmt_misc挂载为根因。六、关键转折目标层级下移6.1 测试multi-user.target在 GRUB 中在linux行末尾添加systemd.unitmulti-user.target结果仍然卡死。结论❌ 排除图形界面服务。6.2 测试rescue.target在 GRUB 中在linux行末尾添加systemd.unitrescue.target结果仍然卡死。结论❌ 排除multi-user.target特定服务。6.3 测试emergency.target在 GRUB 中在linux行末尾添加systemd.unitemergency.target结果仍然卡死。DeepSeek 判断仍然怀疑binfmt_misc或 snap。ChatGPT 判断开始怀疑问题发生在 systemd 启动之前建议systemd.device_watchdog参数。关键转折点emergency.target是 systemd 最精简的启动模式它只启动sysinit.target中的基础服务。如果它都卡死问题一定在sysinit.target层或更早。6.4 测试systemd.device_watchdog在 GRUB 中在linux行末尾添加systemd.device_watchdog30 systemd.device_watchdog_timeout30结果仍然卡死。deepseek方向无效。七、决定性突破init/bin/bash7.1 ChatGPT 的关键提问“如果init/bin/bash都卡死那问题不在 systemd不在用户态服务而在内核与硬件的交界处。”7.2 执行init/bin/bash在 GRUB 中在linux行末尾添加init/bin/bash启动后屏幕显示bash: cannot set terminal process group (-1): Inappropriate ioctl for device bash: no job control in this shell root(none):/# [USB 枚举日志...]实际状态屏幕显示了root(none):/#提示符。键盘完全无反应按任何键都没有输入回显。Num Lock 灯熄灭CtrlAltDel无反应。这不是“进入了 bash”而是“bash 刚打印出提示符系统就硬锁死了”。7.3 对init/bin/bash结果的解读DeepSeek仍然怀疑是 systemd 某些服务的残留影响或binfmt_misc在 kernel 层面的循环。未充分重视“Num Lock 灯灭”这个信号。继续在 systemd 层面思考。浪费我大量时间。ChatGPT立即识别出这是硬死锁Hard Lockup。指出Num Lock 灯灭意味着 CPU 停止响应中断这是内核/硬件层面的问题。放弃所有 systemd/snap/bin 方向转向APIC/PCI/ACPI/CPU 电源管理。建议测试底层参数noapic、irqpoll、pcinomsi、intel_idle.max_cstate0。八、最重要底层参数测试8.1noapic irqpoll在 GRUB 中在linux行末尾添加noapic irqpoll结果仍然卡死。结论❌ APIC 中断方向不是根因。8.2intel_idle.max_cstate0 processor.max_cstate1在 GRUB 中在linux行末尾添加intel_idle.max_cstate0 processor.max_cstate1结果仍然卡死。结论❌ CPU 电源管理 C-State 不是根因。8.3pcinomsi✅在 GRUB 中在linux行末尾添加pcinomsi结果成功进入系统结论✅ MSI消息信号中断是根本原因。九、pcinomsi的含义与后续验证9.1 参数说明MSIMessage Signaled Interrupt现代 PCIe 设备使用的中断机制比传统 INTx 更高效。pcinomsi强制内核禁用所有 PCI 设备的 MSI回退到传统 INTx 中断。9.2 验证pcinomsi后系统表现✅ 系统正常启动进入桌面。✅ NVIDIA 驱动正常工作nvidia-smi可用。⚠️ USB 初始化变慢出现xhci_hcd: Timeout while waiting for setup device command。⚠️ 但系统没有卡死USB 超时只是禁用 MSI 后的副作用。9.3 排除其他设备nomodeset无效 → 不是 NVIDIA DRM/KMS拔掉 USB 外设无效 → 不是外设问题NVMe 工作正常nvme0: 1/0/0 queues→ NVMe 不是根因十、pcinomsi的副作用及后续处理10.1 副作用ChatGPT 提供影响严重程度说明PCIe 设备性能略降⭐⭐中断效率降低NVMe SSD⭐连续读写可能下降几个百分点USB 初始化变慢⭐⭐已看到 Timeout 日志网卡/WiFi 高负载⭐⭐CPU 占用可能略高GPU⭐几乎无影响电池续航⭐影响很小10.2 VSCode 无法打开报错内部错误请报告运行 code 失败timeout waiting for snap system profiles to get updated原因之前排查时执行了sudo systemctl mask snapd.service snapd.socket snapd.seeded.service忘记解除屏蔽。解决sudo systemctl unmask snapd.service snapd.socket snapd.seeded.service sudo systemctl start snapd sudo systemctl enable snapd结果VSCode 恢复正常。10.3 永久应用pcinomsisudo nano /etc/default/grub # 修改 GRUB_CMDLINE_LINUX_DEFAULTquiet splash pcinomsi sudo update-grub10.4 可选锁定稳定内核sudo apt-mark hold linux-image-5.15.0-67-generic linux-headers-5.15.0-67-generic十一、为什么-67正常而-139坏的最终分析11.1 内核差异5.15.0-672022 年底发布PCIe 中断处理代码较保守。5.15.0-1392024 年后更新包含了 Intel Raptor Lake 平台的 PCIe MSI 优化补丁。11.2 硬件组合Intel Raptor Lake Refreshi7-14650HXIntel 700 系列 PCHMediaTek MT7925 Wi-FiUnion Memory NVMe SSD特定 BIOS 版本S9CN13WW11.3 BIOS 状态变化用户误触 BIOS 设置后按 F2 进入 BIOS 点了一下某个选项又点回来改变了 PCIe 设备的 IRQ 路由方式使得原本隐藏的 MSI 死锁暴露出来。11.4 结论Linux 5.15.0-139 在联想 Y7000P 2025 上某个 PCIe 设备高度怀疑 Intel xHCI USB 控制器启用 MSI 后触发了内核级硬死锁。pcinomsi禁用 MSI回退到传统 INTx绕过了该兼容性问题。十二、后续排查方向ChatGPT 建议如果未来想“精准定位”而不是“一刀切”可以依次测试intel_iommuoff如果有效问题在 IOMMU MSI 组合pcinoaer禁用 PCIe 高级错误报告pcinommconf禁用 MMCONFIG检查联想官网是否有 BIOS 更新十三、命令执行结果汇总表以下是用过的指令遇到相同问题可以参考。序号命令/参数执行结果是否解决问题1mokutil --sb-state✅ 成功❌ 排除2dkms status✅ 成功❌ 排除3df -h /boot✅ 成功❌ 排除4ls -la /boot/initrd.img-*✅ 成功❌ 排除5uname -r✅ 成功确认环境6sudo update-initramfs -u -k 5.15.0-139✅ 成功❌ 无效7snap changes✅ 成功❌ 排除8snap list --all✅ 成功❌ 排除9journalctl -u snapd --since 7 days ago✅ 成功⚠️ 线索10sudo systemctl mask snapd...✅ 成功❌ 无效11grep ... /var/log/apt/history.log✅ 成功⚠️ 线索12zcat ... grep linux-firmware✅ 成功⚠️ 线索13dpkg -l grep linux-firmware✅ 成功⚠️ 线索14sudo systemctl mask proc-sys-fs-binfmt_misc.automount✅ 成功❌ 无效15sudo systemctl unmask snapd...✅ 成功✅ 修复 VSCode16nomodeset(GRUB)❌ 卡死❌ 排除17systemd.unitmulti-user.target(GRUB)❌ 卡死❌ 排除18systemd.unitrescue.target(GRUB)❌ 卡死❌ 排除19systemd.unitemergency.target(GRUB)❌ 卡死❌ 排除20init/bin/bash(GRUB)⚠️ 硬锁死❌ 排除用户态21systemd.debug-shell(GRUB)❌ 无反应❌ 排除22systemd.device_watchdog30(GRUB)❌ 卡死❌ 排除23noapic irqpoll(GRUB)❌ 卡死❌ 排除24intel_idle.max_cstate0 processor.max_cstate1(GRUB)❌ 卡死❌ 排除25pcinomsi(GRUB)✅成功启动✅找到根因26sudo nano /etc/default/grubsudo update-grub✅ 成功✅ 永久修复27sudo apt-mark hold linux-image-5.15.0-67...✅ 成功✅ 双重保险28sudo apt remove linux-image-5.15.0-139...⚠️ 未执行N/A
