Ubuntu 26.04 迁移全记录

TL;DR 与症状速查表

一台机械革命耀世（Core Ultra 9 275HX + RTX 5090 Laptop）从 Windows 11 迁移到 Ubuntu 26.04 LTS 的完整记录：可行性评估、驱动基线、以及三个月内逐项排查的六个主要问题。总体结论：能迁，且 26.04 对这套硬件的支持远超旧教程的描述；但每一项电源管理默认值背后都有一笔需要亲自核算的账。

带症状来的读者直接查下表，点击跳转对应章节取修复结论；其余章节按时间线与问题域展开，各章结论前置。

阅读路线

• 修问题：速查表直达。

• 学方法：每章「本章小结」沉淀了该案例的可迁移判据（取证纪律、验证分层、计数时效、权威源核查、例行触发器评估），跨章主线为「默认值不等于最优值」与「偶发故障的验证纪律」。

• 做评估：「迁移决策」一章的四维评分框架与行动清单可直接复用于其他机型的迁移前评估。

硬件环境一览

各章另有独立的「本章环境」框，记录该问题发生时的内核与驱动版本——本文跨三个月，版本在演进，判读数据时请以对应章节的环境为准。

迁移决策：硬件兼容性评估与迁移结论

现象：需要将深度学习开发环境由 Windows 11 迁移至 Ubuntu，前提是所有硬件获得完整驱动支持。
结论：迁移可行，Ubuntu 26.04 LTS（kernel 7.0）为该硬件组合的最优选择；评估期识别的最高风险项（特定机型声卡）经机型核实后不命中，实际剩余风险为有线网卡一项。
处置：确认机型；Live USB 试跑验证全部硬件；按优先级安装 NVIDIA 驱动与 CUDA、处理有线网卡、配置双显卡切换。

本章环境：评估阶段，系统为 Windows 11；目标系统 Ubuntu 26.04 LTS（kernel 7.0）；硬件配置为 Intel Core Ultra 9 275HX、RTX 5090 Laptop、Intel Xe2 集显、Intel AX211 Wi-Fi、Realtek RTL8125B 有线网卡。

评估方法

迁移决策前的逐项硬件评估采用四维评分：驱动可用性（官方或社区驱动是否存在）、功能完整性（性能、电源管理、高级特性是否完整）、安装复杂度（是否涉及内核编译、手动签名、固件提取）、社区验证度（同配置成功案例数量）。综合评定分为高、中、低三级风险。

该框架的实际价值需要说明：评分最低的项目最终未构成障碍，而后续消耗主要排障时间的项目在评估表中仅列为中等风险。评估的作用不在于预测全部问题，而在于将决策所需的最低验证量压缩至一次 Live USB 试跑可以覆盖的范围内。

逐项评估结果

独显（RTX 5090 Laptop）：低风险。 Ubuntu 26.04 对 NVIDIA 的支持较 2024 年时期的教程环境有实质变化：驱动与 CUDA 已进入官方仓库，发行版 release notes 明确背书 NVIDIA 的 Wayland 完整支持，Blackwell 移动端的休眠缺陷已在上游修复。安装路径缩减为：

sudo apt update
sudo apt install nvidia-driver-580-open cuda-toolkit
sudo reboot
nvidia-smi    # 验收

两项保留条件：Secure Boot 需在 BIOS 禁用或走 MOK 签名流程；Blackwell（RTX 50 系）架构仅支持 -open 变体内核模块，闭源分支不覆盖该架构。

CPU（Core Ultra 9 275HX）：中风险，已有解。 Arrow Lake-HX 平台存在已确认的 intel_pstate 频率计算缺陷：BIOS 未在 ACPI CPPC 中正确编程频率值，持续负载下 CPU 频率锁定在约 1.6–1.8 GHz（标称加速频率 5.4 GHz）。该缺陷已被 Ubuntu 内核团队确认，临时处置为切换内核参数：

# /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="... intel_pstate=passive"
sudo update-grub && sudo reboot
grep "cpu MHz" /proc/cpuinfo | head -8    # 验证频率恢复

选择 26.04 而非 24.04 的依据在于 kernel 7.0 对 Arrow Lake 的原生优化：新架构平台的电源管理与核显支持随内核版本演进，旧内核 LTS 将损失该部分能力。

有线网卡（RTL8125B）：中风险，处置明确。 内核内置 r8169 驱动可识别该 2.5GbE 芯片，但存在 2.5G 链路协商失败、ASPM 行为异常、随机断连三类问题。社区方案为安装 r8125-dkms 并屏蔽 r8169。该问题后续的实际演化超出「安装驱动」的范围，详见「安装与驱动基线」一章。

声卡：评估期高风险项，实际不命中。 公开资料表明部分搭载 AW88399 编解码器的机型（典型为 Legion Pro 7i Gen 10）在主线内核无驱动，需提取 Windows 固件并编译定制内核。经按资料所述方法核实本机型号后确认：本机不在受影响名单内，声卡开箱即用。

该项需要单独记录，因为它是评估结论中一个方法论意义的案例：评估报告的最大风险项建立在未经核实的前提上（「机器可能为某型号」）。迁移准备的第一步应为机型确认，而非风险项处置。

双显卡切换及其他硬件：低风险。 PRIME render offload（on-demand 模式）为 NVIDIA 官方支持的成熟方案，默认核显驱动桌面、按需调用独显。两项注意事项：GNOME 50 已移除 X11 会话，仅保留 Wayland（NVIDIA 已完整适配，早期「Wayland 闪帧退回 X11」的经验不再适用）；笔记本 HDMI/DP 通常直连独显，on-demand 模式下外接显示器可能无输出，需临时切换 prime-select nvidia 或确认 MUX 配置。Wi-Fi（AX211）、蓝牙、摄像头、键盘背光、TPM 2.0 均开箱即用。

迁移行动清单

按优先级排列的处置清单：

1. 确认机型，判定声卡风险（约 1 分钟，决定迁移可行性判断）。

2. 制作 Ubuntu 26.04 Live USB，试跑模式实测全部硬件（约 30 分钟，将纸面评估转为实测）。

3. 安装驱动与 CUDA：nvidia-driver-580-open cuda-toolkit。

4. 处理有线网卡：r8125-dkms 加 r8169 黑名单。

5. 验证 CPU 频率缺陷是否仍需内核参数；配置 PRIME on-demand。

本章小结

行动清单中的 P0 两项（机型确认、Live USB 试跑）与 P1 两项（驱动、网卡）均按预期兑现。未预见部分在于：后续三个月的主要排障工作不发生在「硬件不可用」层面，而发生在「各项电源管理默认值与硬件能力不匹配」层面——睡眠、独显休眠、功耗墙、游戏渲染归属等在评估表中均为低风险的项，构成了后续各章的主体。迁移难度的分布可以概括为：评估覆盖「让系统可用」，其余部分依赖逐项调优。

安装与驱动基线：RTL8125B 网卡的双重定性

现象：板载 RTL8125B 有线网卡在内置 r8169 驱动下出现 2.5G 链路协商失败、ASPM 异常、随机断连；数月后出现 PCIe AER 错误风暴，最高一次会话产生 22,771 行相关日志并导致整机硬挂。
结论：该网卡存在两个层面的独立缺陷。软件层面为 r8169 驱动不可靠，r8125-dkms 可修复；链路层面为板级 PCIe 缺陷（与驱动无关），上游存在已 bisect 的驱动回归但不能解释本机症状，社区无「换板修复」闭环案例。
处置：软件层安装 r8125-dkms 并屏蔽 r8169；链路层在 BIOS 中永久禁用板载 LAN，以 AX211 Wi-Fi 及扩展坞有线口兜底。

本章环境：Ubuntu 26.04 LTS，kernel 7.0.0 系列；板载 Realtek RTL8125B 2.5GbE（PCI 地址 0000:83:00.0，根端口 0000:80:1c.6）；对照设备为同板 Intel 82599ES 万兆卡、Intel AX211 Wi-Fi 6E。

软件层修复

装机后的有线网卡问题与评估预期一致。内核内置 r8169 可识别 RTL8125B，但三个症状同时存在：2.5G 协商失败并锁定在 100M/1G、ASPM 行为异常、随机断连。标准修复为社区维护的 r8125-dkms 驱动：

sudo add-apt-repository ppa:awesometic/ppa
sudo apt update && sudo apt install realtek-r8125-dkms
echo "blacklist r8169" | sudo tee /etc/modprobe.d/blacklist-r8169.conf
sudo update-initramfs -u && sudo reboot

lspci -knn | grep -A3 Ethernet    # 验收：Kernel driver in use: r8125

安装 r8125 后链路协商与稳定性恢复正常，软件层面问题关闭。

硬件层故障：首次爆发与临时处置

首次硬件层报警出现在电池供电加深睡眠之后的使用场景：内核日志出现 PCIe AER（Advanced Error Reporting）错误爆发，单次会话产生 22,771 行相关日志，限流峰值约 29,136 次/5 秒；伴随独显驱动 probe 失败、设备从总线消失，整机硬挂，只能强制断电。

首次处置按最简假设执行：BIOS 中禁用板载 LAN。禁用后设备及其根端口一并从系统消失，AER 计数归零，故障闭环。

复发实测与条件无关性验证

约两个月后，为验证「睡眠是否为触发条件」，在 BIOS 中重新启用该网卡。复发实测结果如下：相同错误签名在完全不同的条件下复现——交流供电、无睡眠事件、无网线连接，开机 23 分钟后爆发一批可纠正错误，根端口计数 152 次后自限，系统未受影响。

两次爆发对比如下：

据此可将两个事实分开陈述：其一，「电池 + 深睡眠」不是触发必要条件；其二，端口启用状态下，该链路在常规闲置条件即可产生可纠正错误，只是规模不再致命。

上游与社区证据

复发后执行五路调研（中文社区、英文社区、内核上游、售后条款、上游回归补齐），主要结论：

• 同型号存在公开记录。 同模具机型（同方 X6 平台，多家厂商贴牌）存在「有线网卡 WHEA 报错」的公开视频记录与社区反馈，Windows 与 Linux 社区的症状描述一致指向板载 Realtek 有线网卡。但未发现任何「确诊 → 更换主板 → 修复」的闭环案例，存在「换板后复发」的反面记录。

• 上游存在驱动回归，但不能解释本机。 kernel bugzilla #221606 记录了 r8169 的 LTR（Latency Tolerance Reporting）回归，并已 bisect 至具体提交（v7.0-rc1 引入）；本机内核确认包含该提交。但上游报告者的触发条件为手动开启 L1.1 ASPM，而本机 ASPM 三档全部关闭仍复现。软件层标准 workaround（关闭 ASPM）在本机处于默认状态，等于无可用 workaround。

• 跨品牌社区处置一致。 同平台贴牌机型的社区在遇到同类以太网 WHEA 报错及死机后，一致建议 BIOS 禁用板载 LAN，与本机首次处置相同。

最终处置

综合三层证据——本机复发实测（条件无关性）、社区证据（同型号风险聚类成立但非必然）、上游状态（回归处于 open 状态且无修复）——最终处置为 BIOS 永久禁用板载 LAN。该机器具备 AX211 Wi-Fi 6E（全程稳定）与 Thunderbolt 扩展坞有线口作为替代链路，禁用代价为零。

本章小结

该案例的排查过程包含两次定性，各成立一半：第一次按软件缺陷定性（r8169 不可靠），成立，但属于表层；第一次爆发按「睡眠触发」处置（禁用），有效，但复发证明触发条件更宽。硬件类故障的证据需分层审查：软件层症状（驱动报错）与链路层症状（AER 计数）共享同一表象，归因路径完全不同——前者更换驱动，后者仅剩禁用或换板，而换板无修复先例。

至此硬件基线全部收束：CPU、核显、独显、Wi-Fi、声卡、外设正常；有线网卡以永久禁用结案，为迁移期唯一确诊的硬件级问题。其余问题均发生在软件与配置层。

合盖睡死：症状、归因修正与缓解处置

现象：笔记本进入睡眠后黑屏，键鼠与电源键均无响应，只能长按电源键强制断电。
结论：初步归因「BIOS 的 s2idle 实现不成熟」在 16 小时内被日志证据推翻。实际根因为 i915 驱动在 Arrow Lake / Meteor Lake 平台的 C10 PHY 上、面板断电后重新点亮时未重新编程 PLL，属于 v6.19.13 至 v7.0.3 之间的驱动侧上游回归；上游修复补丁（drm/i915/mtl+: Enable PPS before PLL）当时尚未进入 Ubuntu 26.04 仓库。
处置：分两层。「睡眠后能否正常唤醒」由 deep（S3）模式解决，已通过 GRUB 参数 mem_sleep_default=deep 固化并通过三次实测验证；「面板重新点亮黑屏」在官方修复落地前只能缓解：禁用自动熄屏、避免合盖、开启 SysRq 兜底。官方修复的落地过程见「内核升级、SRU 与桌面细节」一章。

本章环境：Ubuntu 26.04 LTS，kernel 7.0.0-31-generic；BIOS N.1.18MRO24（2025-08-06）；内屏 2560×1600（BOE NE160QDM-NM9）由核显（PCI ID 8086:7d67，i915 驱动）输出；独显 RTX 5090 Max-Q 为无显示输出的 offload 卡；内存 61 GiB，swap 为 8 GB /swap.img 文件。

现场取证

故障 boot 在故障时刻戛然而止，无正常关机记录。journalctl -b -1 -n 80 重建的最后一段内核日志：

i915 0000:00:02.0: [drm] *ERROR* [CRTC:150:pipe A] mismatch in dpll_hw_state
i915 0000:00:02.0: [drm] DPLL 0: pll hw state mismatch
WARNING: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:4945
  at verify_single_dpll_state+0x2a6/0x6b0 [i915], CPU#21: KMS thread/5526
  intel_dpll_state_verify+0x63/0x260 [i915]
  intel_atomic_commit_tail+0x8a3/0xc50 [i915]
  drm_atomic_commit+0xad/0xf0
  drm_mode_atomic_ioctl+0x7d1/0x910
Hardware name: MECHREVO YAOSHI Series/YAOSHI Series-X6AR55xY, BIOS N.1.18MRO24 08/06/2025

机理解读：崩溃点不在睡眠路径，而在核显显示管线的显示时钟校验——verify_single_dpll_state 发现 DPLL 硬件状态与软件记录不一致后 modeset 提交卡死，DRM 挂起并拖垮图形会话。外在表现「睡死」，内在机制「显示时钟校验失败导致图形栈挂死」。调用栈自 drm_mode_atomic_ioctl 起，属 userspace 发起的 modeset，不是 resume 路径——这一点在根因改判后回头看尤为关键。

Linux 在此类场景有一项对排障有利的性质：强制断电不丢日志（journal 持久化），睡死类问题的理想流程是先取证再断电，但真卡死时唯一出路是长按，事后重建现场即可，不必为留证据长时间等待。

判据有效性：通用手段在本机的失效与替代

按标准手法，第一步应区分「内核已死」与「内核存活但显示未恢复」，常规判据是 Caps Lock 键帽灯。本机上该判据不成立：

兜底手段当时也缺失：kernel.sysrq=176（Ubuntu 默认掩码）未开键盘触发位，REISUB 不可用；图形会话挂死后切 tty 无效。

处置与修正：放弃键盘灯判据；补 /etc/sysctl.d/99-sysrq.conf 写入 kernel.sysrq = 1，此后卡死可 Alt+SysRq+REISUB 同步磁盘后重启，不再强制断电。存活判据强度排序：ping 通 > 能切 tty > Caps Lock 响应 > 任何灯效/背光。边界：标准 HID 键盘（无独立 MCU）的 Caps Lock 仍是有效判据，不应一概否定；ping 判据要求机器当时联网，走 deep 时网卡随总线掉电，ping 不通不必然等于内核死了。

候选根因排除

动手修复前对三个候选根因逐一查证，每条均可在短时间内证实或证伪：

1. hibernate（休眠到磁盘）失败：排除。/sys/power/resume 与 resume_offset 从未配置；swap 8 GB 文件对 61 GB 内存物理上装不下休眠镜像；systemd-hibernate-clear.service 每次开机因 HibernateLocation efivar 缺失而 skip，证明从未成功休眠。用户口中的「休眠」实为 GNOME「睡眠」（suspend）——两条电源路径不先分清，后续全部动作都会打偏。

2. 键鼠唤醒源未授权：排除。USB 层 power/wakeup 权限正常，但 /proc/acpi/wakeup 所有设备的 S-state 清一色 S4，BIOS 未为低功耗睡眠态暴露唤醒路径；「短按电源键也无反应」本身否定了「仅收不到唤醒信号」——那是收不到信号，这是整个系统不响应。

3. NVIDIA 驱动：排除。nvidia-suspend/resume/hibernate 三 unit 均 enabled，驱动链路就位；崩溃栈完全落在 i915 符号内，无 nvidia 条目。

方向确认：内屏由核显输出，DPLL 是核显的显示时钟。混合显卡机器上「黑屏」的第一嫌疑人是负责内屏输出的那颗 GPU 的 modeset 路径，判据依据是崩溃栈所在模块符号，而不是硬件价格或直觉。

修复假设与分段验证

假设：本机 BIOS 的 s2idle（Windows 称 Modern Standby）实现不成熟，切真 S3（deep）可绕开 DPLL 状态残留。验证刻意走两段式，第一段可逆、零风险：

# 第一段：sysfs 临时切换，重启自动失效
echo deep | sudo tee /sys/power/mem_sleep && cat /sys/power/mem_sleep && sudo systemctl suspend
# 唤醒后立即核查
journalctl -b -k | grep -i dpll        # 期望：无输出
cat /sys/power/suspend_stats/*         # success=1 fail=0

可行性依据（均实测）：内核日志含 ACPI: PM: (supports S0 S3 S4 S5)；/sys/power/state 注册了 freeze/mem/disk；/sys/power/mem_sleep 显示 deep 可用未选中。首次 deep 睡眠 61 秒，正常唤醒，suspend_stats 干净，DPLL 零报错。

验证通过后才固化进 GRUB（带备份 grub.bak-sleep），并处理了两个操作层细节：grub.cfg 为 root-only（0400），普通用户无法直接 grep 验证生成结果，只能以源文件 + update-grub 输出间接确认，最终裁决点后移到重启后；/proc/cmdline 确认参数传入、/sys/power/mem_sleep 显示 s2idle [deep]，固化成立。

当日下午的验证结果一度非常干净：三次 deep 睡眠全部成功（61 秒手动、10 秒合盖、8 秒合盖，后两次在 GRUB 固化之后），DPLL 报错零复发，合盖唤醒路径同样验证通过（systemd-logind: Lid closed → suspend entry (deep) → exit → Lid opened 完整配对两次）。注意这组结论后来如何被推翻，见下节——它正是「计数型结论必须带时间窗」的实证。

归因修正：16 小时的结论寿命

次日复查，journalctl --list-boots 排出的新证据将昨日结论全部推翻。关键反证：一个 /proc/cmdline 确认 deep 生效的 boot 里，DPLL 报错链复发 6 次（00:29、01:44、02:32、05:12、05:56、09:52），同一 boot 的 PM: suspend entry 计数为 0——该 boot 整夜未进睡眠（sleep-inactive-ac-type='nothing' + 到点只熄屏），却报出全套睡死签名，最终以强制断电收场。未发生睡眠的 boot 里报错照发：睡眠路径不是触发条件，deep/S3 只解决了「睡下去能不能醒」这一半。

重新归因依赖对报错原句的上游检索。mismatch in dpll_hw_state 精确命中一组已定性工单：i915 gitlab #16042 / #16098、Debian #1141719、Launchpad #2165830——同一核显 PCI ID、同一 [CRTC:150:pipe A]，其中 Launchpad 单明确注明「It is NOT a suspend/resume issue — no system suspend occurs」。实际根因：i915 在 Arrow Lake / Meteor Lake 的 C10 PHY 上，面板断电后重新点亮时未重新编程 PLL，属 v6.19.13 → v7.0.3 的驱动侧回归。触发条件是任何让面板真正掉电再点亮的操作：DPMS 自动熄屏、锁屏、合盖、s2idle、S3——这也是 deep 睡眠本身能成功唤醒（内核活着）而合盖醒来后经常黑屏（面板没点亮）可以并存的原因。

机理的确定性证据：c10pll_rawhw_state 回读全 0，而源码中 __intel_cx0_read() 在 msgbus 三次失败后 return 0——全 0 的语义是「根本没读到」，不是「PLL 没锁」。上游修复补丁将 intel_pps_on() 提前到 DPLL 使能之前（commit 062499cc，Intel 维护者 Imre Deak），已进入 stable 7.1.6 与 mainline 7.2；Ubuntu 26.04 仓库当时最高 7.0.0-31，尚未 backport。本机 xe 驱动虽在但 refcount 0，Intel 官方支持表把 ARL 归在 i915 名下，且 xe 的 KMS 代码与 i915 共享同一套——切 xe 不治此病。

报错链每次一模一样，完整签名（排障时按此锚定检索）：

Failed to bring PHY A to idle → PHY A Read/Write 0c70 failed after 3 retries
→ Timeout waiting for DDI BUF A to get active → Timed out waiting for DP idle patterns
→ [CRTC:150:pipe A] flip_done timed out → mismatch in pixel_rate + mismatch in dpll_hw_state
→ pipe state doesn't match!

无效的规避手段与当时的缓解层

四个常用 i915 规避参数经上游工单与本机双向确认无效：i915.enable_psr=0、i915.enable_dc=0、i915.enable_fbc=0、i915.enable_panel_replay=0。唯一实测效果是把 3 分钟以上的死屏压缩到 30–45 秒自愈，属减症。

官方修复落地前的缓解层：

缓解层的代价如实记录：合盖与自动熄屏两个笔记本核心使用场景被放弃，「睡眠」功能名存实亡。

跨操作系统的独立佐证与遗留问题

佐证：该机器 Windows 时代（6 月）已因同类问题被处置为「AC/DC 均永不睡眠、切断 Modern Standby」（s2idle 的 Windows 对应实现），两个操作系统独立得出同一结论——这台板子的 s2idle 实现存在固件层缺陷。限定适用范围：该互证只覆盖「s2idle 睡死」一半的问题，不解释 i915 点亮黑屏，两个问题合并归因将导致再次误诊。BIOS 层的外溢缺陷（内核三处点名：s2idle、SW_LID 不合规、UCSI duplicate altmode）按 deep 绕开处理，查新 BIOS 挂账。

遗留问题（当时口径）：真修复依赖上游 backport（等待 SRU）；长时睡眠未覆盖（三次验证最长 61 秒，后随根因改判降级）；hibernate 物理不可行（swap 8 GB < 61 GB 内存）；唤醒瞬间的 PCIe AER 报错（ACSViol，Non-Fatal）判为可忽略噪音；PHY A failed to request refclk 后证实与黑屏同走 C10 PHY A 通路，并入同一上游缺陷跟踪；硬断电后的 journal corrupted 提示为断电必然结果，不作排查线索。

可复用方法论

睡死三步定位法（适用所有 Linux 笔记本/mini PC，/sys/power/suspend_stats 为内核通用接口）：

# 1. 确认走的是哪条电源路径、有没有更优路径可选
cat /sys/power/mem_sleep          # 方括号项 = 当前生效，如 [s2idle] deep
cat /sys/power/state              # 内核注册了哪些状态
journalctl -b -k | grep -iE 'ACPI: PM: \(supports'

# 2. 睡死现场取证（断电重启后仍然可用）
journalctl -b -1 -n 80 | grep -iE 'ERROR|WARNING|BUG|RIP:|end trace|Hardware name'
# 边界：若该 boot 是正常关机收尾，最后一段日志就不是故障现场，
# 先用 journalctl --list-boots 找出无正常关机记录的那个 boot

# 3. 定量判定睡眠成败，别只看「屏幕亮没亮」
cat /sys/power/suspend_stats/{success,fail,failed_resume,last_failed_dev}
journalctl -b -k | grep -iE 'suspend entry|suspend exit'   # 配对即成功一次

s2idle → deep 两段式切换：sysfs 临时验证（重启失效、零风险）在前，GRUB 固化在后；引导参数验收只看 /proc/cmdline；固化必带备份与回滚命令。适用条件：mem_sleep 同时列出 s2idle 与 deep 且内核日志包含 S3；只列 s2idle 的机器（Tiger Lake 起大量机型 BIOS 砍掉 S3）须先去 BIOS 找 S3 选项或转修 s2idle 本身；sed 锚点与实际 GRUB_CMDLINE_LINUX_DEFAULT 不符时会静默不改，必须靠 grep 那步发现；systemd-boot 机器改 /boot/loader/entries/*.conf。

验证类结论的证据纪律：优先取磁盘产物而非对话记忆——当日会话中把「合盖路径」「多次睡眠」列为未验证项，扫 journalctl --list-boots 才发现两项实际都已通过；但「到此刻为止没复发」不是「已修复」，「3 次成功零复发」类计数必须写成带时间窗的断言（本案例该结论仅维持约 16 小时）；拿到报错原句先去上游核对是否已知 bug，本次漏了这步，把一个已定性回归当成未知疑难，误诊一整天。另外松散 grep 会造假计数（grep -c lid 命中 2617 行，锚定 logind.*Lid (closed|opened) 后真实值为 2），统计模式必须收紧到可区分大小写或带上下文前缀。

本章小结

本章记录了一次完整的归因修正：第一版结论（BIOS 的 s2idle 实现不成熟，切 deep 解决）基于当时可得的全部证据成立，16 小时后被同一系统的日志推翻。修正后的根因（i915 C10 PHY 未重编 PLL）来自上游已定性工单，处置转为缓解层加等待官方修复。方法论主体：判据先在本机验证、候选根因逐条排除后再动手、sysfs 先试 GRUB 后固化、计数结论带时间窗、拿到报错原句先去上游检索。

同一根因的第二条战线——上游补丁存在而发行版未跟进时，自行编译替换在用驱动模块的尝试——见「内屏 DPMS 黑屏与 i915.ko 实验」一章。

更新（2026-10-28）

写作本文时的本机复核：已重启进入 7.0.0-38-generic，cat /sys/module/i915/srcversion 实读值为 AD9B846A7B0941179320D5F，即携带官方修复（drm/i915/mtl+: Enable PPS before PLL）的驱动已在位运行；idle-delay 现为 900（自动熄屏已重新开启），黑屏触发路径处于开放状态。按本章的措辞纪律：修复件在位只证明「官方修复已在运行」，不等于黑屏根治，疗效以日常使用被动观察为准；本章所述缓解层（不熄屏、不合盖）中「不熄屏」一项已解除，「合盖睡眠」的疗效证据同样在收集中。Launchpad #2165830 检索仍有上游讨论记录、工单未关闭，精确状态以工单页为准。

内屏 DPMS 黑屏与 i915.ko 实验

⚠️ 风险提示：本章涉及替换正在使用的内核显卡驱动。模块被内核拒收时，内屏将退回固件降级态（simpledrm），表现为分辨率降级、画面闪烁、无法熄屏；该状态不损伤面板（eDP 为数字信号，面板自带时序控制器），但足以造成系统故障的误判。本章结论为负：补丁疗效从未被证明，维护成本为实，最终主动拆除。本章的产出为方法论，不推荐复现操作本身。

现象：上游 i915 修复补丁存在但 Ubuntu 未 backport，自行编译补丁版 i915.ko 替换系统模块。
结论：前两次装载被内核以 Invalid relocation target 拒收，根因为构建脚本中 --disable DEBUG_INFO_BTF 配置级联关闭 DEBUG_INFO_BTF_MODULES，使编译期 struct module 较运行内核少 24 字节；第三次装载成功并运行约两天半无复发，但因目标故障为偶发、干净样本不具区分力，疗效无法确认，最终于官方内核带修复之前拆除补丁。
处置：不建议复现。若必须替换在用驱动模块，应先以「与发行版同规格模块比对 this_module 重定位落点」预判内核可接受性，避免以重启作为探针。

本章环境：Ubuntu 26.04，kernel 7.0.0-31-generic；混合显卡笔电，Arrow Lake 核显（8086:7d67）驱动内屏；补丁 drm/i915/mtl+: Enable PPS before PLL（2,984 字节）；Secure Boot 已禁用；构建产物 strip 后 10,117,496 B（未 strip 约 192 MB，含 9 个 .debug_* 段）；发行版对照模块 11,000,073 B；内核构树 2.4 GB。

背景与方案选择

内屏熄屏后点亮黑屏或分辨率降级，内核报 PHY A failed to request refclk、DDI BUF A state mismatch，与「合盖睡死」一章确认为同一条 C10 PHY 通路。本章开始前已用 idle-delay=0（永不自动熄屏）作为缓解层，实际已规避触发；因此本章目标不是「修复黑屏」（痛感受缓解层压制已趋近于零），而是验证补丁能否根治，并把实验做成可重建、可撤销的资产。

方案评估记录三条路线的排除依据：

• 回退到上游报告所述 last-good 内核版本（报告者称 -29 良好）：不成立。逐 boot 对账证明本机新近安装，-14 只跑过两次 boot 合计约 1 小时、从未走过熄屏→点亮路径，且 refclk 报错在该版本时代已存在——本机不存在「已知良好内核」。别人给的 last-good 版本号是别人机器的账，移植前必须先用 journalctl --list-boots 核对本机是否真的跑过并测过那个版本。

• 等待 Ubuntu SRU：当时渠道判死（修复在 7.1.6/7.2，7.0.y 上游 EOL，Launchpad 单 Incomplete 无里程碑）。

• 自编单模块换装：确定路径。构建踩平三条坑：缺 libdw-dev、必须走 M= 外部构建、产物需 --strip-debug。

开工前执行了风险陈述，四要素此后成为本机所有高风险系统操作的模板：爆炸半径（仅向 updates/ 写一文件加重建索引，不碰内核镜像、initrd、分区表、EFI、原版模块）；撤销路径（删文件 + depmod + 重启，写成非 rm -rf 形式以通过本机命令守卫）；最坏情况与退路（显示异常一次，重启仍可进桌面执行回滚，GRUB 保留旧内核，不存在进不去系统的死局）；风险下限（当时判断「内核收不收」不可预检，下限为一次重启——该判断后被证伪，且这一证伪正是本章最重要的产出）。

前两次装载失败：一次自产误诊的完整解剖

装载手法本身为标准流程（updates/ 目录 + depmod -a + 重启），装载前离线检查全绿：modprobe 解析路径正确、vermagic 与运行内核逐字一致、depends 与发行版一致、srcversion 已变为补丁版取值。重启后的实际状态：i915 未被加载，内屏退回 simpledrm，分辨率爆炸、画面掉帧。日志里的真实拒收信号：

i915: module verification failed: signature and/or required key missing - tainting kernel
module: x86/modules: Invalid relocation target, existing value is nonzero for sec 77, idx 1, type 1

第一行是任何未签名模块都会打的预期 taint，与拒收无关；第二行才是拒收本身——apply_relocate_add() 在模块 init 之前即拒收，与启动顺序、内核参数、签名全部无关（Secure Boot 实测 disabled，签名嫌疑独立排除）。但在当时，这组信号的读取方式犯了一个结构性错误：

按猜测关键词过滤日志（bad relocation|disagrees about version|unknown symbol），零命中后下了「日志无报错」的结论，随即从可读源码构造出「启动竞态」假说——补丁模块体积更大、加载更快，抢在 nvidia-drm 注册前 init，撞上「固件驱动在场则 modeset 默认关闭」分支，init 返回 -ENODEV 被静默回收——并给出「修法」i915.modeset=1。第二次装载带该参数，依旧失败，假说被本机实验推翻。

这个错误链的每一环都典型：关键词没猜中（真实措辞是 Invalid relocation 不是 bad relocation）→ 零命中被误读为「无报错」→ 自洽假说只去找支持它的证据 → 诱导一次无谓的重启。修正动作只有一条纪律：取证一次抓全量再筛，词表来自加载路径的失败类别清单（签名、版本、符号、重定位、taint、init 返回码），不来自联想；自洽假说必须配一个「若为假则可被单次实验推翻」的判据，并尽早跑。

另有一处记录层面的教训：后来 runbook 曾把「预期 taint 1 条」与「拒载信号 0 条」并成一句计数——把预期噪声与失败信号并成一类，等于造了一条会双向误导的门（噪声出现时读成失败，噪声本应出现时读成记录不可信）。判据句子必须一类信号一条、各自带自己的期望值。

拒收的可复现性验证：补丁版 boot 的 Invalid relocation target 计数各 1 次，发行版 boot 各 0 次，与启动参数无关（带 modeset=1 复测无效），与签名无关——当天唯一一条干净的因果链，头号嫌疑随之锁定构建产物本身（事后 strip-debug 与 BTF 配置两个候选）。

根因：24 字节的结构体偏差

根因排查全程离线完成，未消耗重启。链路六步：

1. 定位 sec 77：内核加载器跳过 SHT_NOBITS 段单独编号，与 readelf -S 的 ELF 原始索引可能错位；把全部段列出来对齐后确认 sec 77 = .rela.gnu.linkonce.this_module（模块对 struct module 本体的重定位段），段大小 0x30 = 2 条重定位，分别为 init_module @ +0x138 与 cleanup_module @ +0x490（用 struct 直接解 ELF 比 readelf -r 文本稳）。

2. 排除事后 strip：内核加载器有加固检查——重定位目标内存必须为零。读两个目标位置的文件字节，均为 0——「事后 objcopy --strip-debug 残留」的首要嫌疑当场死亡：内核看到的非零值只能是它自己在加载过程中先写进去的。

3. 对照发行版原线：同段同样 2 条，init_module 同样 +0x138，但 cleanup_module 在 +0x4a8。差 24 字节。

4. 24 字节的来源：include/linux/module.h 中 struct module 的条件字段里，唯一恰好 24 字节的是 CONFIG_DEBUG_INFO_BTF_MODULES 开启时的四个 BTF 字段（两个 unsigned int + 两个指针，4+4+8+8）。

5. 交叉排除：构建用 .config 与 /boot/config-$(uname -r) 实差 30 条配置，与上述 #ifdef 取交集只命中 DEBUG_INFO_BTF_MODULES——残余风险基本清零，也因此敢在重编前就预测落点会回到 0x4a8。

6. 根因陈述：构建脚本当年为「少装依赖」写的 --disable DEBUG_INFO_BTF 级联关掉 DEBUG_INFO_BTF_MODULES，编译期结构体比运行内核小 24 字节，exit 指针被编进加载器已填值的字段位置，加固检查拒收，init 之前 -ENOEXEC。vermagic 与符号 CRC 都对得上仍被拒——那些是身份检查，字段布局是另一道门。而 pahole 本机已安装，那个「依赖问题」从来不存在。

这条根因的账单形态值得单独记录：一次「为了少装依赖而改 CONFIG」的捷径，代价是一整天加两次重启。对付它的正确武器极便宜——读 16 个字节证伪旧假设，再拿发行版同规格模块比对落点，5 分钟、零风险。通用判据：任何「为绕开依赖/步骤而偏离发行版构建基线」的 CONFIG_ 改动，先 grep -n '#ifdef CONFIG_XXX' include/linux/module.h 问一句它有没有往跨边界结构里加字段；改完必跑 diff <(grep ^CONFIG_ .config|sort) <(grep ^CONFIG_ /boot/config-$(uname -r)|sort)。

两道强门与弱门的实证

修复为删除该行配置并重编，落点回到 +0x4a8。同时补强两道离线校验门，均做反向失败测试（对已知应失败的对象必须返回 FAIL）：

原有 vermagic / srcversion / depends 三项校验被实证为弱门：旧产物在这三项全 PASS 的情况下仍被内核拒收两次。只会 PASS 的门不是门，是装饰——校验项必须各自对应一个可证伪的物理事实。

两道新门的工程细节（换机复用的坑位清单）：objdump -d 不带 -r 会把跨文件调用显示成「调用下一条指令」，grep -c 假性为 0（同一坑当天踩两遍）；重定位记录符号名带 -0x4 后缀（PLT32 指向 call 后一条），精确匹配会全灭；对照组锚「被移动的函数」会因其被内联而取到空函数体，要锚「宿主动作」；全量重编 17 秒（24 线程）这种反常速度要拿 CC [M] 行数与 .o mtime 验证而非直觉否定；kbuild 可能跳过依赖集不含 autoconf.h 的对象，须 touch 强制重编消除混 ABI 风险；产物缺 .BTF 段无害（btf_module_notify() 对 btf_data_size == 0 直接放行），但 CONFIG_DEBUG_INFO_BTF_MODULES 关着才致命——区别在字段是否进结构体，不在段是否存在。

PATCH_GATE 同时回答了「官方以后更新内核时如何识别修复是否进来」：Ubuntu 二进制内核包不带 changelog，版本号增长不等于补丁进入；补丁的语义会在产物里留下必然的结构痕迹，上游不给可读变更日志时，从产物里找「补丁必然留下的结构差异」当判据，本案例判别干净（补丁版 1 / 发行版 0，两值恰好对应补丁的唯一语义改动，无误判余量）。

第三次装载：预测兑现与疗效验证的结构性限制

第三次装载后重启，验收判据逐条满足：srcversion 读回补丁版取值 4A0B27F7…；内屏重新绑定 i915、分辨率正常；拒载类报错为零。特别地，ABI_GATE 在编译完成时即预测了「内核将接受该模块」，重启仅为兑现——自此，替换在用驱动模块的接受性判断不再以重启作为探针。

疗效验证受故障偶发性约束，需要结构性降温：目标故障为偶发事件，曾在未打补丁的原版驱动上观察到「102 秒真实熄屏后点亮正常、零报错」的对照样本，因此单次干净样本不具备区分力。观察期设计为被动累积，最终样本账：

样本的取证规范（每次按此排除替代解释）：先证窗口非空（避免「猜测关键词零命中」式假阴性）；确认机器闲置期间日志基线不断流（唤醒尖峰与所述时刻吻合）；逐条归因窗口内的无关报错（pcieport AER ACSViol 为雷电/USB 链路、NVRM nvAssertFailedNoLog 为独显驱动历史老毛病，远早于换装，均不得记成「引入的新问题」）。样本强度定位：原始故障的偏好条件是长时间熄屏后点亮，28 分钟接近「必然不发作」的下限，10.5 小时落在故障真实发生过的条件区间且跨整夜待机；合盖 deep suspend/resume 补上「整卡掉电再醒」这条独立路径（DPMS 期间显卡全程 runtime_status=active，不覆盖该路径）；冷启动样本补第三类触发路径但不具区分力（原版冷启动本就不黑屏）。

四天累计 0 次黑屏、0 条复发信号。工程层面（产物合法、装载成功、运行无反证）宣布收工；疗效层面不做结论——「不再新增决策」不等于「修复确认」，偶发故障的反证强度只能随时间累积。

观察期配套的两条判据级发现：其一，「APT 不会自动推新内核」类否定式判据是错的——本机装着 linux-image-generic-hwe-26.04 元包（会滚），叠加 vermagic 钉死，一次普通 apt upgrade 就能让补丁静默失效且零症状；否定式判据必须先把同族元包名列举一遍。其二，判定系统状态要区分发行版默认与用户改写——「接电源闲置不挂起」是被写进 dconf 的（schema 默认是 suspend），判「某 gsettings 值是默认还是被改过」别只看 gsettings get，拿它和 schema 的 <default> 对，出现在 dconf dump 里就是被显式写过。

观察期提前结束时如实记录的缺口：末段 boot 内没有可证实的熄屏样本（mutter 默认不记 DPMS 转换、探针未运行）——日后重启观察，先把探针跑起来，否则时长再久也攒不出点亮样本。判据教训：DRM 节点编号跨 boot 互换（i915 拿 card2 时内屏是 eDP-1，拿 card1 时独显侧空节点显示 eDP-2），任何写死的 cardN-eDP-M 都只是当时快照，判据必须写成「先按 device/driver 找到 i915 那颗 card，再读它下面的 eDP-*」。

拆除：按终点线收场

拆除发生于装载成功约八天后，决策依据一句话：疗效从未被证明，维护成本是实。成本项：模块不受包管理器追踪；vermagic 钉死内核版本，每次升级静默失效且零症状；补丁范围外出现新故障签名（原子提交 EINVAL，不同族）。前提变化：上游修复已进入 mainline 7.2 与 stable 7.1.6，任何新内核基线 rebase 自动携带——「等待官方」由不可证伪变为存在确定性终点，手工覆盖层的存续理由必须重新计算，当年没算这笔账是补丁多活八天的直接原因。通用判据：当「等官方」从不可证伪变成可机检（本仓即 PATCH_GATE 打在候选内核的 .ko 上），手工替代方案的存续理由就要重新评估。

拆除流程与安装对称（备份 → 校验和回验 → 回验过了才删 → depmod），idle-delay 设回 0；全部产物归档为可重建资产（含装机件样本、反例夹具、MANIFEST 与 SHA256SUMS）。配套修正：「归档表里的路径是承诺，工作区清理后必须回头改表」——曾出现文档按死路径引用已移位取证文件的情况，归档目录与清单已重建。

方法论精选（换机复用）

路径型故障的「触发证明 + 事件开窗」两段判据：先以 2 秒采样探针（while :; do cat /sys/class/drm/*eDP*/dpms; sleep 2; done）证明触发路径真的发生过，再只在点亮事件之后的窗口里统计报错（journalctl --since 取点亮时刻，不是开机时刻）。两条硬判据前置：srcversion 证明目标组件在位且是预期那颗；探针证明路径走过。任一不成立，「0 次」就是假阳性——实测 i915 未加载的 boot 上计数恒 0，因为产生报错的分组组件根本不在场。

离线校验是弱门：重编发行版单模块时，vermagic/depends/符号 CRC/补丁落点四项离线全过不等于能装（本案四项全过仍被拒收两次）。弱门可保留，但必须打印自身边界；「内核愿不愿加载」只有重启后看 /sys/module/<mod> 才算（模块当前未加载时 insmod 可当场预检，属例外）。

「这个包会不会随升级滚动」= 查反向依赖：apt-cache rdepends --installed <版本绑定包>，空 = 不随滚动且是 autoremove 合法目标；找发行版元包补链（先 apt-get install -s 演练，装后重跑同一条命令复验——安装成功不等于追踪链建立）。凡名字带版本号的包都要问一句「谁负责把它带到下一个版本」。边界：rdepends 非空只说明不会被当孤儿删，仍须 modprobe --show-depends 确认内核实际解析到哪颗；元包也可能让 full-upgrade 因解析不到匹配版本而拒升内核。

「内核会不会收这颗 .ko」= 比对 this_module 重定位落点：加载器的加固检查要求重定位目标为零；init_module / cleanup_module 两条 R_X86_64_64 的落点直接由编译期 struct module 布局决定；发行版模块天天加载成功，其落点就是 ground truth——产物落点与它不一致必然被同一道检查拒收，不用重启就能判。边界：只证明「愿意加载」，不证明「补丁治好了 bug」；没有发行版对照模块时不适用；落点一致 ≠ ABI 全一致（只覆盖带重定位的字段）。

文档化的可复验命令是活代码：曾出现「反例复验命令」的双重假通过——命令只 source 函数体取不到脚本全局变量（门走 SKIP 分支根本没跑）+ 管道吞掉退出码，「绿退出码 + SKIP 消息」被当成功。三条例：被单独调用的函数不得依赖调用方全局变量（自取默认值）；禁止行号区间提取代码，一律按函数名；判定只认退出码 + 机器 verdict 行，「结论 | 过滤器」的组合要用 PIPESTATUS。脚本一重构，这类命令就静默失效，且失效形态通常是 SKIP 而非报错。

本章小结

本章的完整弧线：回退路线不可移植 → 两次被拒收与一场自产误诊 → 24 字节根因与两道强门 → 装载成功与四个不具区分力的干净样本 → 按终点线拆除。工程层面它验证了「换在用驱动的接受性可以不重启预检」；疗效层面它没有产出任何修复证明，而这正是拆除理由。负载最重的一条经验不在内核本身：任何「为绕开依赖而偏离发行版构建基线」的开关，都可能往跨边界结构里加字段；而当「等官方」从不可证伪变成可机检，手工方案的存续理由必须重新计算。

后续（09-23 至 10-05，梗概）

补丁在 09-23 随内核升级至 -34 时重编过一次（干净树暴露脚本两个顺序性坑：make kernelrelease 硬引用未生成的 auto.conf、外部构建的 modfinal 缺少 scripts/module.lds 前提；参数化修复后五门 5/5 PASS）；09-24 拆除；同日向 Launchpad #2165830 投递 SRU 佐证评论；10-05 复核发现修复早在 09-04 已随例行 stable 批次打包进同基线 7.0.0-38（比评论早 20 天）——「毕业发生了，但不是我们推动的」。完整时间线与错因分析见「内核升级、SRU 与桌面细节」一章。

RTD3 冷启动卡顿：显卡唤醒延迟定位与处置

现象：Chromium / Electron 系应用（Chrome、微信、QQ、钉钉等）点击启动后先出现数秒无响应再打开窗口；纯 GTK 应用无此延迟。
结论：延迟来自独显 RTD3 电源管理。独显空闲时进入 D3cold 深度断电，应用启动枚举 GPU 时同步等待唤醒，实测单次唤醒耗时 3.15 秒。修复为在 /etc/modprobe.d/ 以同名文件整体覆盖发行版配置，写入 NVreg_DynamicPowerManagement=0x00 关闭 RTD3。
处置：同名覆盖后重启验收。实测代价为独显空载由断电转为常醒，功耗 7.8 W，按电池容量折算轻度使用续航减少约 2 小时。代价与收益（每次冷启动减少 3 秒等待）的取舍由使用场景决定。

本章环境：Ubuntu 26.04，NVIDIA 595.91.07 open kernel module（后复验于 610.57.04）；独显 PCI 地址 0000:02:00.0，位于带热插拔属性的 PCIe 槽位之后；会话为 GNOME 50 + Wayland；电池 89.78 Wh（设计 99.07 Wh）。

症状分类：先量化，再决定优化谁

原始报告把浏览器、终端、设置三类应用的启动延迟合并描述。逐项量化后结果分化：字体缓存 6 ms、DNS 45 ms、D-Bus 无异常、无信号风暴、CPU 频率与负载正常——常规嫌疑全部排除；strace 实测纯 GTK 应用（gnome-control-center）从 execve 到首个 DRM 帧仅 0.17 秒。终端与设置类应用不存在该延迟，问题域收敛为 Chromium/Electron 系特有的约 3 秒等待。该分类步骤避免了把不慢的路径做一遍无效优化；前置的「Preload 是否需要」评估结论是不装（61 GiB 内存仅用 9.5 GiB、NVMe 系统盘、目标应用均非 snap，预读守护无收益）。

根因定位：高频状态采样

证明「启动延迟花费在显卡唤醒」没有采用 strace 时间轴分析（首次解析其时间戳格式即告失败），也没有用合成器截图接口（普通用户调 org.gnome.Shell.Screenshot 报 Access denied），而是高频采样一个「会被抢走」的资源状态位：一个终端以 0.04 秒间隔轮询独显电源状态，另一个终端冷启动 Chrome（临时 profile，不碰用户会话）：

watch -n0.04 'cat /sys/bus/pci/devices/0000:02:00.0/power_state; \
              cat /sys/bus/pci/devices/0000:02:00.0/power/runtime_status'
google-chrome --user-data-dir=/tmp/chrome-bench-profile --no-first-run about:blank

观测结果：Chrome 启动后 1.3 秒内独显自 D3cold 翻转为 D0 并保持；对照组（gnome-control-center、终端）采样 90 次均为 D3cold，全程不触发独显唤醒。唤醒耗时单独测量（间隔 12 s 不操作后测）：/usr/bin/time nvidia-smi -L 睡眠态 3.1 s / 3.15 s，GPU 热态 0.01 s。延迟机理：0000:02:00.0 挂在 HotPlug+ 属性的 PCIe 槽位之后，D3cold 唤醒包含一次链路重训，非单纯通电。

根因陈述：Chromium 启动路径枚举/打开 NVIDIA 的 GL/Vulkan 设备，同步等待 D3cold 唤醒。「固定几秒的一次性等待」这一症状形态是硬件电源态切换的指纹——CPU 争抢与网络等待不呈现该形态，该方法也查不出这两类原因。

两轮无效修复及共因分析

正确定位之后，修复先走了两条弯路，两轮均在用户重启后暴露失效，其结构值得完整记录。

弯路一：udev 规则写 power/control。 设计意图是不改驱动参数，由 udev 在设备事件时把 power/control 写为 on。当场验证全部通过：on/D0、静置 90 秒零翻转、Chrome 冷启动降至 91/92 ms。用户重启后失效：日志中存在规则写值记录，读回却是 auto——有更高优先级的写者把它改了回去。

弯路二：补充 bind 时机规则。 grep 定位到 71-nvidia.rules 在设备绑定时把 power/control 写回 auto，据此补 ACTION=="bind" 规则、靠文件名字典序压后，并用 udevadm test --action=bind 在不重启的前提下验证了规则命中顺序（该方法本身有效）。用户再次重启，仍失效。

两轮误判的共因：只证明了「存在其他写者」，没有证明「存在唯一写者」。 从单条命中规则推导唯一根因之前，必须先排除「驱动运行时自行接管」一类不受 udev 规则顺序约束的写者。按猜测叠加规则，等价于与不可见的写者循环竞争。附带代价是两次完整的用户重启——这类_sysfs 开关修复的共性教训是：当场数据再漂亮也只是必要条件，持久性只能由重启证明；更早的教训是「多档切换」的初始设计目标本身不成立（驱动参数无供电语义，见下节）。

弯路过程中的操作层记录（换机避坑）：pkill -f 的匹配串出现在自家命令行里会杀掉自己的 shell（逻辑应写进脚本文件 + 精确模式）；udev RUN+= 调用 /usr/local 下的脚本在 initramfs 阶段会找不到（事件发生于 switch-root 前，该路线整体作废）；毫秒计时勿用 uutils coreutils 的 date +%s%3N（zh_CN locale 下输出被污染），用 python3 取时间戳。

权威源核查：写这个开关的三方

网络检索的命中质量低（反向需求居多、互相矛盾），决定性证据来自本机三类权威源：

1. 发行版配置：/lib/modprobe.d/nvidia-runtimepm.conf 仅一行 options nvidia "NVreg_DynamicPowerManagement=0x02"。dpkg -S 查无归属——非任何软件包自带，由 nvidia-prime 生成（prime-select 中路径与取值写死），gpu-manager.service 每次开机重写（文件 mtime 恒为开机时刻后数秒）。原地修改该文件下次开机即被回退，/etc 同名覆盖是唯一持久位置。

2. 驱动行为：驱动源码的 x86 独显探测路径自行启用 runtime PM（闭源 RM 内部），独立于 udev 层；71-nvidia.rules 在 bind 时写 auto 是第二处写者。机制勘误：曾记为「驱动调 pm_runtime_allow()」——610 源码里这组调用只出现在 Tegra iGPU/GenPD 路径，x86 独显不走它，拿 pm_runtime_* 作 grep 关键字会在独显机型上漏判。

3. 参数语义：驱动头文件 nv-reg.h 的原文注释给出四档：0 = 永不断电（默认）、1 = 未初始化时断电、2 = 空闲一段时间后断电、3 = Ampere+ 笔记本按 2 档。没有任何一档区分交流/电池供电——「插电不睡、拔电照睡」的需求在驱动层不存在对应开关，按「0x01 = 仅电池时睡」给出的建议不成立。本机 /usr/src 的驱动头文件是比任何 README 都贴合当前驱动的最高优先级证据。

修复实施与验收

modprobe 配置存在文档化的优先级契约（man modprobe.d）：同名文件先读到的目录生效，后续目录中的同名文件整体忽略。在 /etc 建立与发行版文件同名的完整替换文件：

sudo tee /etc/modprobe.d/nvidia-runtimepm.conf > /dev/null <<'EOF'
# 整体替换 /lib/modprobe.d/nvidia-runtimepm.conf（modprobe: 同名文件 /etc 优先）
# 0x00 = 永不允许独显断电（RTD3 关闭）
options nvidia "NVreg_DynamicPowerManagement=0x00"
EOF

重启前获取不重启的等价证据：modprobe --showconfig | grep -i DynamicPower 仅输出 0x00 一行，/lib 侧 0x02 不再出现——配置解析结果确定后才消耗重启成本。重启后双层验收：/proc/driver/nvidia/params 读到 DynamicPowerManagement: 0（驱动按该值初始化）；端到端 Chrome 冷启动 88 ms，静置 2 分钟独显 D0/active 零翻转。power/control 读回 auto 属驱动掌管，符合预期且不再有意义。最终形态为单一配置文件，无脚本、无 udev 规则、无常驻服务；前两轮的 udev 三件套确认对结果无影响后删除，删后复测确认不睡不依赖任何用户态组件。

同名机制的两条边界：options 行不去重、按文件名字典序累加，内核取最后解析到的那条——覆盖必须同名（本机反例：options nvidia_drm modeset=1 因来自不同文件名出现两次）；/etc/u-d-c-nvidia-runtimepm-override 名字带 override 但语义相反（gpu-manager 的 sentinel，命中后强制尝试启用 RTD3）——见到「看起来正是想要的名字」的开关，先读实现方的字符串或源码，别按命名推方向（strings -a /usr/bin/gpu-manager | grep -i runtimepm）。

代价测量与边界验证

功耗代价（官方文档从不标注，只能实测）：独显空载常醒为 P8、180 MHz、35–36 ℃，功耗 7.8 W。按 89.78 Wh 电池折算，轻度使用续航减少约 2 小时。这笔账的形状：插电为主的场景用 7.8 W 换每次冷启动省 3 秒，划算；移动为主则应重新计算。

睡眠链路边界：关闭 RTD3 后的合理担忧是系统睡眠受影响。当日合盖实测：deep 睡眠 success=1 fail=0，往返正常，唤醒后 DynamicPowerManagement 仍为 0、独显链路正常，睡眠链路四个 NVIDIA unit 均正常完成。runtime PM 与系统 suspend/resume 是两条独立链路，一次实测可划清边界——理论推断「应该不影响」永远不如跑一次真睡眠。

关联缺陷的抓捕：收尾体检发现睡眠链路四个 NVIDIA systemd 单元（suspend / resume / hibernate / suspend-then-hibernate）全部 disabled 且无 preset 兜底。根因为此前 purge 旧驱动分支包时，dpkg 按文件名执行 disable，删除的却是新分支的同名符号链接。后果不是「少个服务」，而是显存保留机制（PreserveVideoMemoryAllocations）失去依赖，会造出新的唤醒黑屏签名、污染 i915 黑屏的归因——这是「独显功耗墙」一章故事的直接前奏。以 systemctl enable 恢复四单元，并把「驱动分支迁移后全量核对 nvidia 单元状态」固化为固定检查项。排查此缺陷时的工具坑：dpkg -S /usr/lib/systemd/system/... 报 no match，差点误判 unit 无归属——包元数据记的是 /lib 路径别名，dpkg -S 不做路径规范化，查归属应 dpkg -L <包名> | grep systemd。

合规审计与判据分层

修复稳定运行后执行专项合规审计，价值主要落在证据链修正上：「我们的做法对不对」和「我们记录的理由对不对」是两个独立问题，审计推翻了三条写进文档的旧依据（/lib 文件的归因、驱动机制说法、以及一条为旧判据新找的替代理由），而更正本身也要再审一次——第四条更正是审上一条更正时发现的。

审计结论：本修复即官方第一条路径（厂商层：525/595/610 三版 README 措辞一致，写 /etc/modprobe.d + 0x00 + 重启；机制层：modprobe.d(5) 同名优先是文档化契约；发行版层：prime-select 只写 /lib、不回退 /etc）。备选六条按官方认可度排序逐一核算成本，无一同时满足「更标准」与「代价 ≤ 7.8 W」：prime-select nvidia 改变显示归属与既有决策冲突；glvnd 环境变量方案等于长期替上游 Open 缺陷打补丁且与 prime-run 冲突，留作功耗不可接受时的备选；BIOS 关独显失去独显；其余参数作用域错配。

initrd 相关判据的订正链条（三层，每层都被下一代证据改写）：最初以「nvidia 不在 initrd」为理由——该证据本身是假阴性（/boot/initrd.img-* 权限 0600，普通用户 lsinitramfs | grep -c 恒 0，结论蒙对但理由是错的）；当晚用户侧 sudo 补跑后正面确认「/etc/modprobe.d/*.conf 会被 mkinitramfs 连 /lib 一起拷进 initrd」，原先那句「/etc 覆盖进不了 initrd」被证伪；最终立足点换成正面事实——nvidia.ko 模块本体不在 initrd 里（整文件名锚定后零命中，全量 668 个 .ko 无一 DRM 显卡驱动），早期阶段无从加载它，「不需要 update-initramfs」由此成立。锚定教训：grep 'nvidia.*\.ko' 会命中 typec_nvidia.ko.zst，判模块存在性必须整文件名锚定 (^|/)nvidia(-[0-9.]+)?\.ko(\.zst)?$。

判据分层的完整版（供换机复用）：参数值看 /proc/driver/nvidia/params（专有驱动不导出 /sys/module/nvidia/parameters/，该路径本机不存在）；驱动状态机看 /proc/driver/nvidia/gpus/*/power 的 Runtime D3 status；内核视角看 /sys/bus/pci/devices/*/power_state；端到端症状（临时 profile 冷启动计时）是唯一能收口的判据。两条自检规则：任何 grep -c 得出 0 之前先证明输入非空；探测命令本身不能改变被测状态（nvidia-smi 会唤醒独显，查占用用 fuser -v /dev/nvidia*）。power/control 由驱动掌管，读回 auto 不代表失效，永远不能当判据。

方法论与边界清单

本章沉淀的三条主判据：其一，往 /sys 写开关之前先做三步权威核查——发行版/驱动包有没有已在管这个开关（最容易被忽略的一步，dpkg -S 区分包自带还是开机生成）；驱动运行时有没有在管（读源码调用链，注意 grep 关键字的平台适用性）；二进制守护进程有没有在写（strings）。只要发现更高优先级写者，就不要走用户态写 sysfs 的路线，改用驱动/发行版的声明式开关。其二，持久性修复先拿不重启的等价证据（modprobe --showconfig、udevadm test、源文件确认），把「重启才发现失败」的成本提前消除；但等价证据只能证明「配置解析结果」，不能证明「硬件真实行为」，两层都要验。其三，同名文件整体替换（modprobe.d / systemd / tmpfiles / sysusers 通用）是文档化契约，覆盖必靠同名。

同类 sysfs 钉值需求的完整行动清单：凡「配置写了不生效 / 生效了又消失」类问题，把「自己日志里写过的值」与「现在读回的值」的矛盾当唯一硬证据，流程为「先证明存在第三方写者（journal 对照）→ 列全写者（udev 规则 + 驱动运行时 + 守护进程）→ 收敛到声明式开关」。一条命中规则只能证明「它会写」，不能证明「它是唯一写者」。

本章小结

本章的弯路成本是两次用户重启加两轮自我推翻，换取三条可迁移判据与一个官方背书的单文件方案。它是「默认值不等于最优值」主题在电源管理层面的完整样本：驱动默认启用 RTD3 对台式机合理，对以应用启动延迟为痛点的移动工作站是一笔需要重新核算的账——而这笔账的形状（3.15 秒对 7.8 W），官方文档从头到尾没有告诉过使用者要自己测。

后续章节记录同一主题在整机性能层面的表现：那块 RTX 5090 的功耗墙，为什么长时间停在 95 W，以及把它抬回 175 W 只需要一个被漏掉的 enable。

独显功耗墙：95 W 至 175 W 的排查与验证

现象：观察到 Steam 界面进程占用独显负载，同时独显功耗上限读数停留在 95 W（平台上限 175 W），一度引发「Linux 显卡调度能力不足、是否回退 Windows + WSL」的评估。
结论：95 W 为固件基础 TGP，95 W 至 175 W 之间的 80 W 属 Dynamic Boost 额度，由 nvidia-powerd 服务在运行时与平台固件协商；该服务处于 disabled 状态（驱动分支迁移时 purge 旧包按文件名 disable 掉了新分支的同名单元，排查时核对了四个 nvidia 单元、遗漏第五个）。启用后 8 秒内功耗上限自 95 W 升至 150 W，随后到达 175 W 上限。
处置：systemctl enable nvidia-powerd，跨重启验证；以自编 CUDA 应力工具执行 15 分钟热浸泡验证长期满载稳定性。

本章环境：Ubuntu 26.04（Wayland）；RTX 5090 Laptop（GB203M，Blackwell sm_120）；整机与 TUXEDO X6AR5xxY 同白牌，官方支持外接水冷；nvidia-smi -q -d POWER 读数 95 / 95 / 95 / 5 / 175 W（Current / Requested / Default / Min / Max）；电池 89.78 Wh（设计 99.07 Wh）；用途为 AI 开发与模型微调。

触发与第一个错误结论：单侧读数的陷阱

排查由 steamwebhelper 进程的 GPU 占用报告触发，用户的直接疑问是：「Linux 下的显卡调用有这么差劲吗？要不要把开发切回 Win+WSL？」

第一轮取证的工具与读数：nvidia-smi（独显 8 W / 95 W、P8、0%、显存 282 MiB）、intel_gpu_top（报 Permission denied，需 CAP_PERFMON，普通用户不可用）、遍历 /proc/<pid>/fdinfo 的 drm-engine-* 引擎计数（核显侧归因：Qoder 54–80%、gnome-shell 14–20%、Xwayland 32%——后者后来确认是我方终端刷屏造成的）。据此下了「steamwebhelper 完全没用 GPU」的结论。

该结论错误，且错误结构有完整记录价值：drm-engine-* 字段仅 i915 驱动提供，NVIDIA 专有驱动不上报此字段——fdinfo 方法对独显完全失效，看到 0 不代表没占用。错误结论当时未被数据打脸，只因独显恰好真空闲；约六分钟后独显状态自行变化（P4 / 34 W / 68%、显存 282 → 693 MiB），nvidia-smi pmon 将负载明确记于 steamwebhelper（SM 56–62%），前一结论被推翻。

方法论结论：混合显卡机型上，进程级 GPU 计量必须核显、独显两侧分别测量（核显用 fdinfo 引擎计数差值，独显用 nvidia-smi pmon），只测一侧不允许下结论。fdinfo 侧还须按 (pid, pdev, client-id) 去重——同一 client 被进程每个 fd 重复上报，不去重会算出 337% 一类不可能值（实测去重前后量级差 5 倍）。

Steam 进程位于独显的机制

steamwebhelper 位于独显的五个环境变量（__NV_PRIME_RENDER_OFFLOAD=1、__GLX_VENDOR_LIBRARY_NAME=nvidia 等）不出现在任何配置文件里——排查 steam.sh、~/.config、/etc/environment.d、运行时二进制均无所获，gnome-shell 自身与其他 GUI 应用也没有，判定为启动时注入。定位路径：进程环境变量中的 GIO_LAUNCHED_DESKTOP_FILE 直接指路，/usr/share/applications/steam.desktop 含 PrefersNonDefaultGPU=true——GNOME 在启动声明该标记的应用时注入整套 PRIME offload 变量，全系统仅此一个桌面项使用该标记。该机制属设计行为非故障，当时未修改（修改会让 Steam 传给游戏的 offload 变量一并消失）；该问题后随 Steam 卸载自然消解。

功耗墙定性：语义判读与唯一控制者

用户提出关键问题：「不应该是 175 W 吗」。nvidia-smi -q -d POWER 三值如下：

Current Power Limit   : 95.00 W
Requested Power Limit : 95.00 W
Default Power Limit   : 95.00 W
Max Power Limit       : 175.00 W

判读链条：Default 与 Current 一致——若墙被人为压过（nvidia-smi -pl），Default 会停在固件值、只有 Requested 变低；三者一致说明没人改过墙，95 W 就是固件给的基础 TGP。95 W 至 175 W 的 80 W 属 Dynamic Boost 额度，由 nvidia-powerd 在运行时依据平台固件报告的整机功耗预算协商，实现方式是临时下调 CPU scaling_max_freq 给 GPU 让电。本机 nvidia-smi -pl 不可用（Requested 恒 N/A），不支持软件写功耗上限——能改这个值的角色只有平台侧 Dynamic Boost，因果闭合。

服务遗漏的归因与时间线排除

nvidia-powerd 状态为 disabled + inactive，但本该 enabled——包 preset 就是 enabled，同机 nvidia-suspend / resume / hibernate / suspend-then-hibernate 四个单元全 enabled，只有它掉队；journal 显示它在驱动分支迁移当日的两个 boot 还正常启动过，之后消失。「包 preset 说该开、实际却是 disabled」这个不一致本身就是「被遗漏」的旁证。直接成因指向前一章的 purge 缺陷：按文件名 disable 打掉了新分支的同名符号链接，排查时核了四个、漏了第五个。

「安装 Steam 拉取的包改了功耗」的假设用时间线排除：Steam 相关包装完于 17:34 / 17:57，21:22 与 21:40 两次实测墙仍是 95 W，21:49:48 服务启动后约 8 秒上限升至 150 W（后自行爬到 175 W = Max）——量的变化时刻与控制者的启动时刻对齐，包管理假设排除。通用判据：数值「莫名其妙变了」时，先查这个量的唯一控制者是否刚被启动，再查包管理历史。

启用路径上的一个概念澄清：systemctl start（立即运行）与 systemctl enable（写入开机自启）相互独立。当时的状态正是 disabled + active——重启即回落 95 W；enable 后重启验证持久化（is-enabled=enabled、is-active=active，175 W 常态化）。

uniwill-laptop 支线：一次顺序错误的示范与能力面对比

为获取风扇/温度可观测能力（acpi_fan 读数 ENODEV），modprobe uniwill-laptop force=1 强载同白牌厂商平台驱动（其 DMI 别名限定厂商名 TUXEDO，本机 MECHREVO 不匹配故不自动加载）。probe 后拿到 hwmon10（fan1/fan2、CPU/GPU 温度、pwm 只读）、ctgp_offset、LED 设备、WMI hotkeys；仍无 platform_profile。

副作用检查发现顺序错了：uniwill_nvidia_ctgp_init() 在 probe 阶段就写 EC——置位三个 CTGP 使能位，且没有 remove 逆操作，rmmod 撤不回。正确的操作顺序应为加载前阅读 probe/remove 源码确认固件写入行为，本次是先加载后查，等于先动手术后读说明书。判据：probe 只读 = 安全；probe 写且 remove 不还原 = 不可逆副作用，加载前必须知情同意。也别用名称判断——「看起来只提供 hwmon 只读属性」的驱动，probe 里同样可能写 EC（本例正是）。写入后实测 NVIDIA 侧静态上限未变（Default/Max 加载前后均 95/175），与 nvidia-powerd 的动态行为是否冲突无法从源码判断，裁定撤载（exit 0，逐项核验驱动目录树全消失，不止看 lsmod）；内核 taint 标志（force 加载所致）保留到重启。

同一驱动引出的「官方 LED 替换自建方案」评估，方法是能力面对比（以 sysfs 实际暴露为准，不以名称判断）：官方 LED 设备仅单色 RGB 加通用触发器，无灯带对应设备、无动画、无灭灯守卫；自建方案（ITE 8291 键盘 9 种动画 + ITE 8233 灯带 5 种 + 会话事件驱动的灭灯守卫）能力面显著更宽——不切换。判据只有能力面与维护成本，不含情怀；反向亦成立，不因「是自己造的」就拒绝替换。

热浸泡验证：工具、判据与两轮结果

本机无现成烤机工具（无 gpu-burn / stress-ng / glmark2），以 nvcc 自编 CUDA 应力工具（FMA 密集循环、每秒一行心跳进度，卡死立即可见），配合 nvidia-smi dmon 每秒采样：

nvcc -O3 -arch=native -o gpu-stress gpu-stress.cu
timeout 950 ./gpu-stress 900 32 &                    # 900 s，32M 元素/数组
nvidia-smi dmon -s pum -c 910 > soak-trace-15m.csv   # 每秒 1 行

负载标定：SM 99%、显存控制器 92–93%、迭代恒定约 2004 次/秒、grid=1312 blocks × 256 threads、显存占用 0.36 GiB。

判据设计三条，缺一不可：温度增量是否衰减（到达热平台的证据，非温度绝对值）；功耗是否稳定贴上限（中途掉落通常意味 EC/固件介入）；有无中断（负载迭代速率恒定 + 轨迹 sm% 无塌陷）。时长必须覆盖笔记本热时间常数（常见 3–10 分钟）。

两轮结果：5 分钟轮温度自 45 ℃ 升至 63 ℃ 且仍在爬升（结束时仍有 +0.5~1 ℃/30 s 增量），未到平台，不能下稳态结论——但「没到平台」不等于危险，判据看离温度墙的余量；延长至 15 分钟后，每分钟采样点为 60/62/63/64/64/65/65/65/66/66/66/66/66/67/66——约 360 s 后走平，平台 ≈ 66 ℃，峰值 67 ℃，888 个满载样本中 0 个超 70 ℃；功耗自 123 W 爬坡至 175 W 后稳定于 173–174 W；全程零 Xid。判定：该机散热与供电可长期支撑 175 W 满载，外接水冷确实扛得住。

风险披露与三层调研

「powerd 默认没启用」是 Linux 生态的结构性默认（上游 README 把启用写成人工步骤、Arch 系 unit preset disabled、Ubuntu 25.04 之前不打包该 unit），但 Ubuntu 25.04 起已默认启用——本机 disabled 属偏离官方默认的本地态。「看起来是驱动或硬件问题」的现象，可能只是某个包少执行了一句 enable；判断前先分层：内核能力 / 发行版打包 / 厂商工具，三层各查一遍。

反面证据如实披露：同代 RTX 5060 Laptop + 驱动 610.43.02 有报告称 enable powerd 后重度 TensorRT 负载可复现黑屏与 Xid 79（GPU 掉总线），禁用后稳定。该证据与本次验证结果并存，不否定本机结论，但说明该开关非零风险——本机以热浸泡加日常观察兜底。

配套计量方法论

util% 的语义判据：utilization.gpu 是「有多少比例的时间在执行任务」，不是算力占比；「干得多重」看 power.draw 对上限；clocks.mem 在低档与高档间来回切 = 反复唤醒。实测样本：12 秒逐秒采样中 util 在 19–21% 与 83–89% 间跳，两组功耗几乎相同（37.2–40.7 W vs 40.3–41.5 W，上限 95 W）——那个 88% 不对应更多实际工作量。真被打满 = P0 + 功耗贴上限不掉 + 频率钉最高，三者缺一就不是。另：util 低不等于没占显存（Steam 常驻约 0.7 GB 显存，挤占微调预算）。

数值异常三步定位：找这个量的唯一控制者（daemon 或 unit，systemctl show -p ActiveEnterTimestamp 看启动时刻）→ 查包管理历史（apt history.log 留完整记录）→ 两条时间线对齐。边界：该量有多个控制者时先确定当前实际生效的那个；注意 Default 与 Requested 的语义差异——判断「上限有没有被人为改过」看这两者是否一致，不是看 Current。

本章小结

本章的定性链完整保留了「数值异常 → 语义判读 → 唯一控制者 → 状态异常归因 → 时间线排除 → 启用与长期验证」的每一步：95 W 本身不是故障信号，Default 一致性证明它非人为压墙；Dynamic Boost 的存在把嫌疑集中到 nvidia-powerd；preset 与现实的差异证明「被遗漏」；两条时间线的对齐排除了包管理；热浸泡给出了 175 W 长期稳定的物证。代价最高的一环仍是「单侧读数不构成结论」——上一次是核显/独显两侧，这一次是「看到 0」与「不存在」的区别。而 95 → 175 W 这 80 W 的实际控制权，从头到尾只在一个没人检查的 systemd unit 里。

Steam 与 Proton 游戏：混合显卡本的游戏栈配置实测

现象：在 Ubuntu 26.04 + RTX 5090 Max-Q 混合显卡笔记本上构建可用的 Steam/Proton 游戏环境，需要覆盖客户端、兼容层、驱动、工具链、显示平台五个层面。
结论：截至 2026-10 实测，该组合的配置结论优于通用教程的预设：渲染归属两项流传结论（「混合显卡默认跑核显」「deep 睡眠命中硬挂矩阵」）在本机实测中均未复现或已被修复；实际需要的处置为安装 Valve 官方 steam-launcher、修复 GameMode 组权限与 CPU 绑定、保持 deep 睡眠配置不动。
处置：按层记录安装形态、Proton 版本策略、驱动分支约束、GameMode 修复与过时参数黑名单。

本章环境：Ubuntu 26.04.1 LTS，kernel 7.0.0-34-generic（基线读数日）→ 7.0.0-38-generic（追记实测日）；NVIDIA 610.57.04 → 615.71.09 open kernel module；Vulkan 1.4.341；Mesa 26.0.8；GNOME 50 + Wayland；gamemode 1.8.2；内存 61 GiB；外接 DP 显示器直连独显，内屏 eDP 由核显输出。

评估框架：按「游戏帧的链路」切五层

按「游戏帧从游戏进程到屏幕」的路径切分，各层独立评估，避免把跨层问题归错层：

数据采集两路并行：本机可自证的读数一律现场实测（sysfs / nvidia-smi / sysctl / dpkg / systemctl），不采信推断；外部结论由独立检索分章收集，区分官方文档与社区经验。冲突处理原则：两个来源不一致时显式并列并标注，不以单一来源下定论。

L1 客户端层

对比对象：Valve 官方 APT 仓库 .deb、Ubuntu 仓库 steam 包、Snap、Flatpak。

结论：选 Valve 官方 APT 仓库的 steam-launcher。 Valve 官方文档明确声明 Flatpak 与 Snap 版「not officially supported」：

steam-launcher 的内容是启动引导器：含 steam-devices udev 规则与最小 Steam，Proton 与 runtime 运行时从 Valve 服务器拉取——这是它能跟随最新 Proton 的原因。

安装要点：sudo dpkg --add-architecture i386；装 32 位图形库时不能让 Mesa 的 Intel/AMD 32 位 Vulkan ICD 混入（lib32-vulkan-intel 与 NVIDIA Vulkan 驱动互斥，典型症状 dxvk::DxvkError）；游戏库放 NVMe 根分区 ext4，不要放 exFAT/NTFS（shadercache 损坏 + SteamApps/steamapps 大小写冲突）。实测安装结果：steam-launcher 1:1.0.0.87，自带 Valve APT 源。

L2 兼容层

版本策略：默认留在 Stable，失败才试 Experimental。官方各 flavor 的定义：

前置检查清单：Steam Play 两个总开关（supported + all other titles）；单游戏可强制指定版本；工具文件校验（库筛选切 Tools，对每个 Proton / SLR 条目 Verify integrity of tool files——官方 FAQ 未覆盖这层，是 Proton 排障关键步）；着色器预编译线程 unShaderBackgroundProcessingThreads 8 写入 ~/.steam/steam/steam_dev.cfg（默认可能只用 1 核）；GE-Proton 解压到 compatibilitytools.d/，仅过场视频黑屏 / media foundation 报错 / 需要 GE 专属 protonfix 时用。

runtime 基线：Proton 11+ → SLR 4.0；8/9/10 → sniper；5.13–7.0 → soldier。网络上推荐 Proton 7.x/8.x 的教程已过期。

L3 图形栈层

本机 610.57.04（生产分支）→ 615.71.09（新特性分支，随 2026-10-09 系统更新自动装入）。核心约束：5080/5090 这一代不存在驱动分支选择——proprietary 分支只覆盖到 Hopper，Blackwell 及以后只能 open kernel module。「装 proprietary 更稳」的建议对此架构无效。

610 已满足全部关键门槛：DXVK 需 Vulkan ≥ 1.4（NVIDIA ≥ 575.51.02）；VK_EXT_descriptor_heap 默认启用（≥ 595.84）；open 驱动 Runtime D3（610 起）；Vulkan HDR WSI 免 layer（≥ 595.58.03，本机不需要 vk-hdr-layer）。

615 与本机直接相关的修复：新增 VK_NV_low_latency rev2（Proton 对 Vulkan 原生游戏 Reflex 的开箱支持）；修复 VK_NV_low_latency2 在 VK_KHR_wayland_surface swapchain 上无法降延迟的 bug——610 上 Wayland 会话里 Reflex 是失效的，这是升级 615 的最强理由；Smooth Motion 卡死修复；「先前 hibernation 过则 resume from suspend 失败」修复。已知代价（官方承认）：open 模块 GPU 初始化更慢、S3/S4/RTD3 进出延迟更长（闲置后首帧可感知迟滞）。

注意实测修订：游戏内 DXVK HUD 读到随附转译层为 DXVK 2.7.1（外部资料所述 3.0 并非 Proton 11.0 实际随附版本），凡挂靠「DXVK 3.0」的结论须按实际运行版本复核。nvidia_drm.modeset / fbdev 自 560.35.03-5 起默认开启，不要手工写内核参数，应改为验证。

渲染归属：一项被实测推翻的流传结论

ArchWiki 原文：「混合显卡笔记本上 Steam 默认使用集成显卡运行游戏」，且 D3D→Vulkan 的 Windows 游戏 PRIME 环境变量对转换层无效，必须直接指挥转换层（DXVK/VKD3D 设备过滤）。

本机实测（样本：《女神异闻录 5 皇家版》，AppID 1687950，Proton 11.0 + SLR 4.0，P5R.exe，未加任何过滤变量，进程环境实测无 DXVK_FILTER_DEVICE_NAME / VKD3D_FILTER_DEVICE_NAME）：

机制线索：内屏场景游戏进程同时打开 renderD128（NVIDIA）与 renderD129（Intel）——Intel Vulkan ICD 被加载用于设备枚举，DXVK 枚举后自主选中独显。这解释了本机未复现「默认跑核显」。

结论修订：「默认跑核显」这一 L2 说法的前提在本组合（615.71.09 + Proton 11.0 + DXVK 2.7.1）下未复现，内屏裸启动即落独显；原 P0「内屏加 DXVK_FILTER_DEVICE_NAME」降级为非必需的预防措施。适用边界：反例仅对本组合有效，不外推其他驱动/Proton 版本。未验证缺口：内屏由核显扫描输出，独显渲染帧需跨 GPU 拷贝至核显，该开销与帧时间劣化未实测（需 MangoHud 帧时间 A/B）。

L4 工具链层：GameMode 从「装了」到「生效」

本机 GameMode 处于功能残缺状态：Ubuntu 的权限授予全部以 gamemode 组为条件（/etc/security/limits.d/10-gamemode.conf = @gamemode - nice -10，polkit 规则亦判 isInGroup("gamemode")），而本机用户名下不含该组（组 gid 974 成员为空）；同时包自带默认 renice=0、[cpu] 段为空。即组件已安装但既不做优先级提升也不做核心绑定。

修复三件套：

sudo usermod -aG gamemode $USER     # 需注销重登

# /etc/gamemode.ini —— [gpu] 段只认 /etc 配置，用户级 ~/.config 会被当 unsafe 忽略
[general]
renice=10            # 默认 0 等于不提升；上限受 limits.d 的 -10 约束，超过会整个失败
inhibit_screensaver=1
disable_splitlock=1

[cpu]
pin_cores=yes        # 上游自动识别 Intel P/E 核，275HX 上避免游戏线程被调度到 E-core

加装 mangohud 与 gamescope（26.04 已进官方仓库，apt 直装）。配合规则：mangohud gamemoderun %command% 顺序固定为 mangohud 在外层；与 gamescope 配合时必须用 --mangoapp 而非 mangohud（否则典型症状 swapchain 报错）。

实测验收（同一样本游戏，gamemoderun %command%）：

renice=10 失效的机制（结构性结论，适用于一切经 Wine/Proton 运行的 Windows 游戏）：Linux nice 是每线程属性；Wine 的 wineserver 按 Windows 线程优先级类逐线程换算并重设 nice（apply_thread_priority 公式 min + (effective_priority − 1) × range / 14）；GameMode 的进程级设置仅作用于它触碰到的线程（实测 72 线程中恰好 1 个为 -10），其余被 Wine 覆盖。配置本身无错（官方注释「the value will be negated」，renice=10 对应 nice=-10，恰在 gamemode 组 limits 允许下限）。结论：Proton 游戏上不要把 renice 当调优手段；GameMode 有效项为 pin_cores、inhibit_screensaver、disable_splitlock。原生 Linux 游戏（不经 Wine）理论上应能保住 renice，可作对照验证（未测）。另注：GameMode 经 --ld-preload=...libgamemodeauto.so.0 注入 pressure-vessel 沙箱，这是它在容器化 Proton 下仍生效的原因。

工具清单：MangoHud 建议装（frametime 判断卡顿比 fps 有用；throttling_status + gpu_power_limit 确认功耗墙）；gamescope 建议装（限帧 + VRR 一致性）；vkBasalt 不装（画质后处理非性能工具）；ProtonUp-Qt 可选（管 GE-Proton）。

L4 笔记本电源与睡眠：一项被实测关闭的 P0

610 时代的论坛实测矩阵：PreserveVideoMemoryAllocations=enabled + nvidia-suspend/resume 服务 enabled → 硬挂（主板码 03，整机无响应只能硬断电）；同帖确认 s2idle 可恢复。上游 issue #1117 另记录 RTX 50 系 + 7.0 内核的 s2idle resume hang（同一驱动在 6.17 正常）。本机基线三项逐项命中矩阵：mem_sleep 选中 deep、三个 nvidia suspend 服务 enabled、PreserveVideoMemoryAllocations=1——当时站在危险一侧。

按「跨代后不再必然适用」的原则先测当前基线（已升 615 + 7.0.0-38）：15:58:56 PM: suspend entry (deep) → 15:59:06 PM: suspend exit，往返约 10 秒；挂起前后同一 boot（无重启记录）——未发生矩阵预测的硬挂；恢复后显卡正常（615.71.09 / 36.92 W / 36 ℃）。

结论修订：原 P0「切 s2idle 并改 GRUB」关闭——保持 deep 不动，仅在实际出现硬挂时启用切换流程。边界：单次通过不等于长期稳定；「先 hibernation 再挂起」路径未覆盖；恢复时的噪音日志（pcieport AER ACSViol、ucsi_acpi failed to re-enable notifications -110、Bluetooth Opcode failed -112）功能正常、留档不复读。

功耗墙侧：真正的性能杠杆是 Max-Q 功耗墙而非 CPU governor——95→175 W 的 80 W 由 Dynamic Boost 在 CPU/GPU 间调配（见「独显功耗墙」一章）；nvidia-smi -pl 不可用；不要装 TLP/tuned（与 power-profiles-daemon 互斥）；governor 手动改 performance 无意义（intel_pstate active 已等价 EPP=performance）；platform_profile 本机固件未暴露，相关建议一律无效；不要往 initramfs 早期加载 nvidia（官方明确破坏 hibernation）；vm.max_map_count 已是 1048576，切勿照抄 SteamOS 的 2147483642。

「swap 8 GB 已满」误读案：排障期间 swap 几乎占满（SwapFree ≈ 16 MB）曾作为性能嫌疑。四路交叉验证：全部 573 个进程 VmSwap 合计仅 555 MB；/proc/meminfo Shmem 13.7 GB（tmpfs 页面计入 Shmem）；/tmp 为 tmpfs 已用 18 GB；vmstat si/so 为 0。结论：swap 占用为 /tmp tmpfs 冷页所致，与游戏性能无关。单一读数（swap 占满）的成因须经独立证据链核对后方可定论。

L5 显示平台层

Wayland vs X11 之争在 Ubuntu 26.04 上已终结：GNOME 50 移除了 X11 后端，会话只剩 Wayland。真正需要避免的是 XWayland——实测附加延迟 +3.13 ms（X11 vs Wayland 差 0.14–0.22 ms），为全章所有单项优化中最大的一项损失。

HDR 评估的验证方法留存（供日后复用）：开启后三路验证——mutter 侧 color-mode 是否变 1（gdbus GetCurrentState）；journalctl --user | grep -i "hdr metadata" 有无 mutter 下发记录；显示器 OSD 是否显示 HDR/BT.2020（唯一不受系统自述影响的证据）。回退：给 nvidia-drm 加 color_pipeline=0。本机该评估当时受 EDID 不可读限制（NVIDIA open 驱动不通过 sysfs 暴露 EDID，全 0 字节），mutter 报 BT.2100 仅为间接证据。

过时信息黑名单

以下流传参数已失效或对本机无效，照抄会在排障时引入伪变量：

侧证：游戏进程环境实测由 Proton 11.0 自行注入 DXVK_ENABLE_NVAPI=1（非用户设置），与黑名单首条方向一致（注意与已废弃的 PROTON_ENABLE_NVAPI 是两个变量）。

明确的信息缺口（不以推断填充）

DLSS 4 多帧生成在 Linux/Proton 下的可用性；Wayland/Mutter 下外接 DP 直连独显时内屏渲染归属与合成开销；prime-select 在 2026 年的官方语义；MangoHud 开销的权威量化；Arrow Lake-HX 上「钉 P-core」的实际帧率收益（机制有依据，收益未 A/B）。

优先级表与执行结果

说明：优先级表达「危害大小」而非执行顺序——三个高优条目没有一个被「安装 Steam」这个动作触发。

本章小结

本章的实测价值集中于两处订正：渲染归属（默认落独显）与睡眠矩阵（本基线未复现硬挂），均为「通用教程结论与特定硬件组合冲突时、以本机实测为准」的样本。工具链层的 renice 失效机制属结构性结论，适用于一切经 Wine/Proton 运行的游戏。配置动作本身（官方客户端、GameMode 三件套、保持 deep 不动）成本合计约一小时，而它的前置成本是五层框架的逐层评估——分层不是形式主义，是把「该信哪条教程」这个问题变成「该测哪项读数」的方法。

CUDA 与 Docker 全栈安装

现象：迁移后需要从零搭建 GPU 深度学习环境：CUDA Toolkit、cuDNN、Docker、NVIDIA Container Toolkit。
结论：最终栈为 NVIDIA 610.57.04 open 驱动 + CUDA Toolkit 13.3 + cuDNN 9.26 + docker.io 29.1.3 + NVIDIA Container Toolkit 1.20，全栈实测可用并跨重启验证。过程中两次基于间接证据的错误推断（文档索引无命中、配置表象缺失）均被端到端实测纠正，构成本章的方法论主体。
处置：升级驱动（冷启动验证）→ 安装 Toolkit 与 cuDNN（注意包名与路径变化）→ 安装 Docker 与容器工具链（注意 1.20+ 的 GPU 注入机制变化）→ 实测筛选镜像加速器。

本章环境：Ubuntu 26.04，kernel 7.0.0-31-generic；RTX 5090 Max-Q（Blackwell sm_120）；初始驱动 595.91.07（open）；安装全程约 3 小时。

错误推断一：文档索引的「无命中」

起点是「安装 CUDA 13.2」的请求。技术文档索引（curated docs index）中 CUDA 13.x 系列仅确认到 13.0 / 13.1 / 13.3，无 13.2 记录，据此推断「13.2 版本号存疑，可能为笔误」——该推断错误。

纠正路径来自本机实测：nvidia-smi 显示 NVIDIA-SMI 595.91.07 ... CUDA Version: 13.2，13.2 真实存在且为该驱动支持的最高 CUDA 运行时版本。进一步的仓库侧实测：curl 直接探测 NVIDIA 官方仓库目录，ubuntu2604 仓库仅含 cuda-toolkit-13-3 与 cuda-toolkit-13-4（无 13.2），ubuntu2404 / ubuntu2204 仓库全版本齐备。即问题不是「版本不存在」，而是「该版本未进入本发行版仓库」。

方法论结论：工具索引的「无命中」不等于事实不存在。curated 索引存在覆盖滞后，涉及版本号、发布状态、仓库可用性的关键事实，须以本机实测命令（nvidia-smi、apt-cache search、直接探测仓库目录）交叉验证。三个命令合计耗时不足 15 秒，结论可靠性高于 10 分钟的索引检索。

驱动与 Toolkit 版本兼容规则

版本兼容关系以实测为准，规则归纳如下：

• nvidia-smi 显示的 CUDA 版本 = 驱动支持的最高 CUDA 运行时版本（610 驱动起字段名变为 CUDA UMD Version，含义不变）。

• 驱动向后兼容：13.3 驱动可运行 13.3 及以下版本编译的程序。

• 驱动不向前兼容：13.3 驱动不能运行 13.4 编译的程序（报 CUDA_ERROR_INSUFFICIENT_DRIVER）。

• 因此 Toolkit 版本必须 ≤ 驱动报告值；610.57.04 实测报告 13.3（非此前推测的 13.4），选定 Toolkit 13.3。

驱动升级的兼容性判断依据一条硬证据：Ubuntu 官方已为 kernel 7.0.0-31 预编译 610-open 签名模块（linux-modules-nvidia-610-open-7.0.0-31-generic），Canonical 对该组合的预验证成立。升级后按已知问题清单采用冷启动（而非 warm reboot）验证，规避 610 的 warm reboot 显示枚举缺陷。

另需记录的两条装机侧经验：桌面会话活跃时 sudo shutdown -h now 会被 GNOME inhibitor 拦截，官方推荐的强制关机方式为 sudo systemctl poweroff -i；Blackwell 架构仅支持 open kernel module。

安装链：命令完整性与包名漂移

两次本可避免的执行失败：

• 首次给出的 Toolkit 安装命令遗漏 wget cuda-keyring_1.1-1_all.deb 前置步骤，执行报「无法访问归档」。交付多步安装命令时须包含全部前置依赖（下载、切目录、配源、刷新索引），不以「用户已完成某步」为假设。完整链如下：

cd /tmp && \
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2604/x86_64/cuda-keyring_1.1-1_all.deb && \
sudo dpkg -i cuda-keyring_1.1-1_all.deb && \
sudo apt update && \
sudo apt install -y cuda-toolkit-13-3 && \
echo 'export PATH=/usr/local/cuda-13.3/bin${PATH:+:${PATH}}' >> ~/.bashrc && \
echo 'export LD_LIBRARY_PATH=/usr/local/cuda-13.3/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}' >> ~/.bashrc && \
source ~/.bashrc && \
nvcc --version

• cuDNN 9 的包结构变化：libcudnn9 为虚拟包，apt 拒绝直接安装，须显式选择 CUDA 版本后缀（本机为 libcudnn9-cuda-13 与 libcudnn9-dev-cuda-13，9.26.0.51-1）；头文件路径由 cuDNN 8 的 /usr/include/cudnn_version.h 变为 /usr/include/x86_64-linux-gnu/cudnn_version_v9.h。大版本跳跃后的包名与文件布局须以 apt-cache search / dpkg -L 实测确认，不凭旧经验。

错误推断二：配置表象不等于实际能力

安装 NVIDIA Container Toolkit 后，验证阶段观察到 docker info 的 Runtimes 字段仅列出 io.containerd.runc.v2 与 runc、Default Runtime 为 runc，未出现 nvidia——据此推断「GPU 容器不可用」。该推断错误。

纠正依据端到端实测：docker run --rm --gpus all nvidia/cuda:13.3.0-base-ubuntu24.04 nvidia-smi 在容器内成功输出 RTX 5090 与驱动版本。机制说明：nvidia-container-toolkit 1.20 及以上改用 CDI（Container Device Interface）+ prestart hook 模式注入 GPU 设备，不再依赖 Docker daemon.json 中的 runtimes.nvidia 配置段；docker info 的 Runtimes 字段仅枚举 OCI runtime，不反映 hook 注入的能力。判断 NVIDIA 容器能力的唯一可靠方法为实测 docker run --gpus all，管理命令输出会误导。

该错误与「文档索引无命中」同属一类：间接证据（索引、配置表象）与事实之间隔着实现机制，关键能力判定必须走端到端实测路径。

Docker 组合安装与镜像加速器实测筛选

Docker 侧组合为 Ubuntu 官方仓库的 docker.io 29.1.3、docker-compose-v2 2.40.3、docker-buildx 0.30.1，加 NVIDIA 官方仓库的 nvidia-container-toolkit 1.20，用户加入 docker 组。一处配置冲突记录在案：安装链中 nvidia-ctk runtime configure 写入 daemon.json 的 runtimes 段，被后续 tee 写 daemon.json（配镜像加速器）覆盖——因 CDI/hook 模式不依赖该配置段，本次未造成后果；若旧版本工具链（< 1.20）或对 daemon.json 有依赖的场景，修改须合并而非覆盖。

镜像加速器按实测筛选，不采信名单：

for m in https://docker.m.daocloud.io https://docker.1ms.run \
         https://docker.xuanyuan.me https://dockerproxy.net; do
  curl -sS -o /dev/null -w "HTTP %{http_code} | %{time_total}s\n" --max-time 8 "$m/v2/"
done
# 判定：HTTP 401 + 短延迟 = 健康（/v2/ 的预期响应）
#       301/302 = 重定向（docker 不一定跟随）；TLS 错误 / 403 / 404 / 5xx = 不可用

3 个候选中 1 个 TLS 失效、1 个重定向；补测后保留 4 个健康 mirror（daocloud、1ms.run、xuanyuan.me、dockerproxy.net）。实测拉取：alpine:latest 10.2 秒，nginx:alpine 6.3 秒（约 20 MB，约 3.2 MB/s）。mirror 健康度属时变属性，配置后仍须定期以 curl /v2/ 复测。

全栈验证在改动 daemon.json 后复测了 GPU 容器能力——修改相邻能力的配置后，必须复测其未被破坏，不能只验证本次修改项。

旁节：一次上游索引事故的本机处置

安装完成次日发生一项与上文相关、责任方在 upstream 的事故，处置流程有独立记录价值。

现象：15:16，apt 全链路瘫痪，任何 apt 命令报 E: Encountered a section with no Package: header，MergeList 指向 NVIDIA CUDA 仓库的 Packages 索引。该时间点前 90 秒恰好执行过 snap 旧修订清理，时序相邻使其成为第一嫌疑。

归因（三重独立证据）：其一，结构判据——坏文件 1,052,657 字节、1,060 个段、末 5 段缺 Package: 头且 Filename: 字段粘连、Size: 0；其二，时序判据——文件 mtime 显示 00:32 为服务器 Last-Modified 写入（apt 会保留远端时间戳），Birth 时间 15:14:33 落在 apt-daily.service 运行窗口（15:14:26–15:14:34）内，即系统定时任务自动拉取且「成功」退出；其三，归责判据——本机文件与上游直连拉取的文件 md5 逐字节一致（986b174b…），与签名 InRelease 声明值吻合。三证合一：上游 NVIDIA CDN 发布了结构性畸形索引，本机无责。上游 GitHub issue #50 的独立报告与本机判定一致。

处置（隔离 → 哨兵 → 恢复）：禁用源（改名 .list.broken）+ 删除本地坏索引，apt 立即恢复，全程约 13 分钟；上游修复前以哨兵脚本定期复测（判据须带输入健全性下限——旧版哨兵在空响应时会把「没下载到」误报为「已修复」，已加固）；上游约 19.5 小时后静默修复（修复版 1,055 段、与签名声明逐位一致），按预置 runbook 恢复源并四连复核（源文件状态、残留索引、缓存可解析退出码、端到端 dry-run）。

该旁节的通用结论：「发现时刻不等于起因时刻」，时序相邻不构成因果，须以机制证据（服务运行窗口、子系统资源交集）归因；源级故障按「先隔离本地、再核实上游、留哨兵等修复」处理，恢复动作必须由哨兵判定触发，不凭时间流逝。

本章小结

本章全部结论可回溯到两条同源纪律：间接证据（文档索引、管理命令输出）不得作为事实依据，关键判定以本机实测与端到端验证为准；多步操作的命令链须完整自包含。安装类任务看似机械，实际是两轮 agent 工作方法缺陷（过度依赖工具索引、混淆配置表象与实际能力）的暴露点，其纠正成本（各一次，均为分钟级）远低于放任的代价（错误的版本建议会级联到重装）。

内核升级、SRU 与桌面细节

现象：三条支线的收尾记录——内核 7.0.0-31 至 7.0.0-34 升级过程中的通道冲突与补丁重编；向 Launchpad 投递 SRU 佐证评论及后续复核发现的时序反转；卸载 WPS 换装 OnlyOffice 后的一轮字体治理。
结论：其一，「冗余但安静」的系统机制须按例行触发器评估风险，DKMS 冗余通道在内核升级 postinst 阶段兑现为死锁；其二，「上游分支已停止维护」推不出「发行版拿不到修复」，Ubuntu 按批次同步 upstream stable，修复在 SRU 评论投递前 20 天已进入同基线内核包；其三，字体治理按「应用报错清单」收口会掩盖字重类缺口，验收判据须升级为 family × style 矩阵核查。
处置：DKMS 以 /etc/dkms/no-autoinstall 官方开关静音；补丁模块按终点线评估后拆除（见「内屏 DPMS 黑屏与 i915.ko 实验」一章）；字体库确立「系统包做基线、用户目录只放缺口」的维护结构并双端归档。

内核升级：例行事件触发隐藏风险

09-23，apt 推送内核升级（linux-image/headers-generic-hwe-26.04 至 7.0.0-34）。此前评估为「低风险、保持现状」的 DKMS 冗余通道（nvidia-dkms-610-open 与发行版预制模块双通道供货）被例行升级触发：DKMS 为新内核构建的模块与发行版预制模块占用路径冲突，安装以非零状态退出，从内核包的 postinst 阶段冒出，导致五个内核包停在「已解压未配置」状态。

处置路径的排除记录：apt remove nvidia-dkms-610-open 会连带卸载驱动元包（rdepends 实测）；dkms install --force 会把 DKMS 产物落进 updates/dkms/，按 depmod 优先级覆盖发行版签名模块，将冗余制度化。最终采用 /etc/dkms/no-autoinstall——dkms 3.4.3 源码中 autoinstall() 首行的官方开关，touch 后 dpkg --configure -a 五包一次归位，nvidia for -34 由发行版通道正常供货。

方法论结论：风险评估中凡「例行事件可触发的理论风险」应按现实风险计——例行 apt 升级、重启、夜间定时任务每周都会执行，「需手动触发才咬人」的前提在例行流水线面前不成立。同类评估还须回答「哪条例行流水线会碰到它」。

补丁跨内核重编与装机纪律

i915 PPS 补丁模块按内核版本目录隔离，内核滚动即静默失效（vermagic 钉死）。为不在无补丁窗口内重启，执行了跨内核预编：构建脚本以 I915_PPS_KREL / I915_PPS_TARGET 参数化，干净构建树上首次完整运行暴露出两个顺序性缺陷（make kernelrelease 硬引用尚未生成的 include/config/auto.conf；外部构建的 modfinal 规则缺少 scripts/module.lds 前提），均以带注释的修复固化。重编产物五门校验全过，srcversion 与 -31 版一致（Ubuntu 两周未改动 i915 源码）。

装机阶段记录一处操作层缺陷：多条 sudo 命令整段粘贴时，密码提示吞掉了末条的 -a 参数，depmod 只刷了运行内核、目标内核的 override 未生效，全程零报错。判定装机成败的依据是目标文件的 mtime 加重查命令（modprobe -S <目标内核> --show-depends i915），不是粘贴回显。修复为逐内核显式执行 sudo depmod <目标内核版本>。

SRU 评论与一场时序反转

「内屏 DPMS 黑屏与 i915.ko 实验」一章结尾留下的悬案——等 Ubuntu backport PPS 修复——在 09-24 有一条主动推进记录：向 Launchpad #2165830 投递 SRU 佐证评论，结构为五段式（第二机复现确认、症状与日志签名原文、正面回答官方最后的提问——修复在 7.2 merge window 中，mainline 7.3 任何构建必然包含、本地验证数据、明确请求 HW-enablement SRU 并自荐验证人）。投递前草稿经证据核对修正两处失实陈述（引用了已被证伪的「-14 已知良好」、把新签名事件混写进老签名），评论最终经 +addcomment 整页表单落库（折叠小表单的动态启用逻辑与自动化填写相性不合，属于操作性细节，不展开）。

当时的判断：7.0.y 上游已停止维护，修复「永不回填」，最早自然通道为 26.04.1 的 HWE 基线（约 2027-01）。

10-05 复核推翻了该判断。对已装入未重启的 7.0.0-38 内核模块执行 PATCH_GATE 二进制判据：发行版 -38 原线为 PASS（对照：-34 为 FAIL、自编译补丁版为 PASS）。38 的 changelog 第 351 行即 - drm/i915/mtl+: Enable PPS before PLL，挂在「Resolute update: upstream stable patchset 2026-08-26（LP: #2165189）」条目下。时间序：修复 08-03 进上游 stable 7.1.6；08-26 Ubuntu 例行批次扫入；09-04 打包进 7.0.0-38；09-24 本机投递 SRU 评论；10-03 该包装入本机。修复进入发行版早于 SRU 评论 20 天。

错因分析：「linux-7.0.y 止于 7.0.14 后停止维护」为事实，但由它推出「Ubuntu 的 7.0.0-xx 永远拿不到修复」跨越了一次对象替换——Ubuntu 内核版本是其自身的发布序列，取料走按批次的 upstream stable 同步，一支 stable 分支停止维护不妨碍另一支（本案为 7.1.6）中的补丁被批次捎入。推理每跨一次对象，须单独取证。配套的另两条教训：「检索零命中」先自证检索本身执行正确（本案中一次 changelog 空命中实为命令被钩子改写未执行）；二进制判据用于下结论，changelog 用于说明来源，两者关系不应对调。

措辞纪律：重启进入 -38 后读到官方修复版的 srcversion，只证明「携带修复的驱动在位」，不证明黑屏根治——该补丁的疗效从未被证明（前章已述）。2026-10-28 复核：该重启已完成，srcversion 实读 AD9B846A7B0941179320D5F 与预期值一致；idle-delay 现为 900，触发路径开放，疗效证据收集中。是否在缓解层重新打开自动熄屏的取舍已由此代际：它现在是既成事实而非待裁问题。

字体治理：两轮盘点与一条验收判据的修正

第一轮（WPS 阶段）。WPS Office 按字体名精确匹配弹出 12 项缺字警告，本机仅有度量兼容替代（Tinos/Arimo、Liberation、Noto CJK 等），替代件一个警告也消不掉。处置为七批安装 67 个字体文件（71 字面、49 个唯一 family），全部经真伪核验（fontTools 读取 name 表 nameID 0/1/5/8/13 加字形数加 cmap 块覆盖率三件套），12 项缺字全部以真件闭合，弹窗归零。

过程中的可记录判据：fc-scan 的 %{copyright} 字段对所有文件恒返回空，属工具盲区，曾据此误判「字体版权信息被剥离」；fontTools 读取 name 表时 platEncID 硬编码会漏读微软符号字体的 (3,0) 编码，当日三次误判均为探测代码自身缺陷；为兜底添加的 fontconfig 别名（prepend + strong）会在真件装入后反过来压制真件，装入真件的第一动作须为删除别名并前后各跑一次 fc-match 验证落点；WPS 仅在进程启动时枚举字体，装完字体须完全退出进程重开。

第二轮（OnlyOffice 阶段，五周后）。卸载 WPS 换装 OnlyOffice 后执行系统盘点（fc-list 1,272 条），发现两类遗留：

其一，用户字体目录与系统的 msttcorefonts 包存在 10 个同名不同版重复件（Arial 四件、Times 四件、Courier、Webdings），md5 两两不同，按 fontconfig 优先级用户目录永久遮蔽系统包。处置为用户目录只保留系统包未覆盖的字体（Aptos、Cambria、Consolas、Wingdings、Symbol 等），Arial/Times/Courier/Webdings 归一到系统包，确立「系统包做基线、用户目录只放缺口」的维护结构。

其二，字重缺口被掩盖五周。第一轮按「WPS 弹窗归零」收口，而 WPS 按 family 名匹配、Bold 缺失不弹窗，等线仅装 Light、Cambria 仅装 Regular 即带着缺口收口。补齐等线 Regular/Bold 与 Cambria Bold 三个真件（多字重家族的 Bold 件须与同源字重交叉比对版本号与版权串）后，验收判据固化为 family × style 矩阵核查：

for q in '宋体' '黑体' '等线' '微软雅黑' 'Cambria' 'Times New Roman'; do
  printf '%-18s regular-> ' "$q"; fc-match -f '%{file}\n' "$q"
  printf '%-18s bold   -> ' "$q"; fc-match -f '%{file} %{style}\n' "$q:bold"
done
# 判读：bold 落点 style 含 Bold = 真件在库；落点为 Regular = 假粗（fontconfig 合成），缺口

边界说明：宋体/黑体/楷体/仿宋在 Windows 侧本就不发布 Bold（加粗走合成粗），不为这四家追 Bold 真件，第三方兜售的「宋体 Bold 真件」为假货高发区。

授权与归档边界。该批字体（微软系、方正系）授权绑定商业许可。本机按自用副本管理：归档仅用于本机与自有设备迁移，不公开分发、不上传公共仓库、不打包进对外发布制品。遵照该边界，本文不附任何字体文件与下载路径，仅记录方法论。全部字体资产按「自包含归档 + 可证明会失败的校验脚本」（安装幂等、verify、verify-installed 四模式，含故意缺失与篡改的负向测试）落盘外置存储，本机与归档双端按固化流程同步（验真 → 安装 → 归档 → 重生成 MANIFEST → verify），不留单边变更。

未解问题清单

截至本文定稿，以下事项处于挂账状态，如实列出：

更新日志

• 2026-10-28：本文首次发布。涵盖 2026-06 可行性评估至 2026-10 的迁移与调优全过程。硬件环境、内核与驱动版本以各章「本章环境」为准；命令与包名会随发行版演进失效，复现前请以实际环境核对。

• 2026-10-28（发布日复核）：本机已运行 7.0.0-38-generic，核显 srcversion 实读 AD9B846A7B0941179320D5F（官方 PPS 修复件在位）；mem_sleep 为 deep；nvidia-powerd 为 enabled；板载 RTL8125B 维持 BIOS 禁用（lspci 无枚举）；独显驱动 615.71.09，power.limit 仍为 N/A。睡死章与收尾章已按此复核更新。

硬件环境脚注（全篇通用）

机型 MECHREVO 耀世 X6AR55xY（同方 X6 平台）；Intel Core Ultra 9 275HX（Arrow Lake-HX，8P+16E）；RTX 5090 Laptop（GB203M，Blackwell sm_120，24 GB）；核显 Intel Arrow Lake-S（8086:7d67）驱动内屏 2560×1600；61 GiB 内存；Wi-Fi 为 Intel AX211；有线网卡 Realtek RTL8125B（BIOS 禁用）；BIOS N.1.18MRO24；系统 Ubuntu 26.04 LTS，GNOME 50 + Wayland；内核 7.0.0 系列（-31 → -34 → -38）；NVIDIA 驱动 595.91.07 → 610.57.04 → 615.71.09（open kernel module）。本文所述症状、根因与修复均以该环境为准；不同机型、内核或驱动版本下的适用性须重新验证。