F4-424 Max QSV 硬件转码触发 i915 内核内存损坏导致系统死机

[keweiyyr]

> 设备：TerraMaster F4-424 Max
> 严重程度：**严重**（可导致整机死机、必须强制断电重启）
> 期望答复：确认内核 i915/QSV 驱动缺陷，提供修复内核或临时规避方案

---

## 一、设备与软件环境

| 项目 | 值 |
| --- | --- |
| 机型 | TerraMaster F4-424 Max（主板标识 `retsamarret 001-004-[F4-424_Max]`，BIOS 5.26 01/17/2025） |
| 处理器 | Intel Core i5-1235U（Alder Lake，10 核 12 线程，含 Xe 核显/QSV） |
| 内存 | 8 GB |
| TOS | 7.0.0804，Build 20260710 |
| 内核 | `6.12.63+ #15`（TOS 定制内核，x86_64，PREEMPT SMP NOPTI） |
| 存储 | 4× Seagate ST8000NM0055-1RM112（8TB）+ 1× WD Blue SN580 1TB（NVMe） |
| 文件系统 | Btrfs（/Volume1 于 NVMe，/Volume2 于 RAID5） |
| 容器化 | Docker Engine 29.4.0（TOS 应用），immich-server v3.1.0 等 12 个容器 |

内核被 TerraMaster 自有 OOT 模块污染（`Tainted: G D OE`）：`scst*`、`tmacl_vfs`、`blk_uevent`、`8812au`、`88x2bu`、`iscsi_scst` 等（O=OOT_MODULE，E=UNSIGNED_MODULE）。

## 二、故障现象

**2026-08-08 18:32 起系统开始反复内核 oops，18:50 后进入僵尸态，22:28 用户强制断电重启。**

死机前系统表现（现场只读观测）：

- 全部端口 TCP 可达、TOS Web 正常响应（毫秒级）；
- **Volume2（机械盘）IO 正常**（普通用户 SSH 公钥校验瞬间通过）；
- **Volume1（NVMe）IO 停顿**（系统管理员 kewei 的 `authorized_keys` 读取挂死，SSH 公钥校验无限卡住）；
- sshd 在公钥校验阶段挂起（内核损坏的伴生症状，非磁盘故障）。

## 三、故障时间线（均为 CST）

| 时间 | 事件 |
| --- | --- |
| 16:24 | 当日早前另有一次异常重启（为排查该次重启部署了 journal 持久化，**本次 81 次 oops 证据正是由此保留**） |
| 16:24–18:32 | 本 boot 正常运行约 2 小时（含 immich QSV 转码） |
| 18:32:13–18:32:17 | immich-server（Docker）执行 **QSV 硬件转码**（HEVC 解码），容器日志：`Transcoding video ... with QSV-accelerated encoding and decoding` |
| **18:32:17** | **首个内核 oops（`[#1]`）**，进程 `Comm: dec0:0:hevc_qsv`（ffmpeg QSV HEVC 解码线程） |
| 18:32:19 | oops `[#2]`、`[#3]`（3 秒内连发） |
| 18:36:02 | oops 已累积到 `[#77]`（进程 uptime-kuma，PID 150813） |
| 18:39:23–18:39:35 | oops `[#78]`–`[#81]`，伴随 `BUG: Bad rss-counter state` |
| 18:45–18:50 | journald 停写（journal 持久化目录恰在 Volume1，被同一 IO 停顿卡死），系统呈僵尸态 |
| 22:28 | 用户手动强制重启恢复 |

## 四、内核崩溃证据（完整 oops 摘录，取自持久化 journal）

```
Aug 08 18:32:17 TWM kernel: Oops: general protection fault, probably for non-canonical address 0xdfff8c2822a40910: 0000 [#1] PREEMPT SMP NOPTI
Aug 08 18:32:17 TWM kernel: CPU: 8 UID: 0 PID: 150016 Comm: dec0:0:hevc_qsv Tainted: G OE 6.12.63+ #15
Aug 08 18:32:17 TWM kernel: Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Aug 08 18:32:17 TWM kernel: RIP: 0010:__kmalloc_noprof+0x106/0x3f0
Aug 08 18:32:17 TWM kernel: Code: 83 78 10 00 48 8b 38 0f 84 8a 02 00 00 48 85 ff 0f 84 81 02 00 00 41 8b 44 24 28 49 8b 9c 24 b8 00 00 00 49 8b 34 24 48 01 f8 <48> 33 18 48 89 c1 48 89 f8 48 0f c9 48 31 cb 48 8d 8a 00 20 00 00
Aug 08 18:32:17 TWM kernel: RAX: dfff8c2822a40910 RBX: 05706900ea89463f RCX: 0000000000000000
Aug 08 18:32:17 TWM kernel: RDX: 00000000a123c008 RSI: 000000000003b0c0 RDI: dfff8c2822a40900
Aug 08 18:32:17 TWM kernel: Call Trace:
Aug 08 18:32:17 TWM kernel: ? __pfx_sg_kmalloc+0x10/0x10
Aug 08 18:32:17 TWM kernel: load_elf_binary+0xe8/0x16f0
Aug 08 18:32:17 TWM kernel: bprm_execve+0x243/0x5e0
Aug 08 18:32:17 TWM kernel: do_execveat_common.isra.0+0x17f/0x1e0
Aug 08 18:32:17 TWM kernel: __x64_sys_execve+0x36/0x40
Aug 08 18:32:17 TWM kernel: do_syscall_64+0x82/0x190
Aug 08 18:32:17 TWM kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e
Aug 08 18:32:17 TWM kernel: ...
Aug 08 18:32:17 TWM kernel: BUG: Bad rss-counter state mm:00000000a23250cf type:MM_ANONPAGES val:1
```

后续 oops（`[#77]`–`[#81]`）**故障地址完全相同**（`0xdfff8c2822a40910`），进程变为 `uptime-kuma`，但调用栈一致指向 `__kmalloc_noprof` 在 `load_elf_binary`（进程 execve）中崩溃。

### 证据要点

1. **首个 oops 的触发进程是 `dec0:0:hevc_qsv`** —— ffmpeg 的 Intel QSV **HEVC 硬件解码**线程命名（`dec<设备>:<流>:<codec>_qsv`），由 immich-server 内的 ffmpeg 以 `--hwaccel qsv` 发起。崩溃上下文含 **`sg_kmalloc`**（i915 驱动的 scatter-gather 表分配辅助函数）。
2. **故障地址 `0xdfff8c2822a40910` 在全部 81 次 oops 中恒定不变** —— 这不是随机值，而是一块**已被释放/被毒化的 slab 内存指针**（非 canonical 地址，CPU 解引用即 GPF）。说明 18:32:17 首次崩溃时某驱动（高度指向 i915）**写坏了内核堆（slab freelist / 对象指针）**，此后任何路径的 `kmalloc` 只要撞上该毒化块就反复崩溃。
3. `BUG: Bad rss-counter state` 与 `Tainted: G D OE` 进一步佐证**内核堆内存损坏**而非普通空指针。

### 级联机理

```
18:32:17 immich QSV HEVC 硬解 → i915 驱动 sg 表/DMA 缓冲管理出现 use-after-free / double-free
→ 毒化某 slab cache（故障地址 0xdfff8c2822a40910）
18:32+ 后续任何 kmalloc（进程 execve 加载 ELF 等）撞上毒化块 → 反复 oops（[#1]→[#81]）
18:45+ 内核内存损坏扩散 → Volume1(NVMe) 文件系统 IO 停顿 → journald/sshd 等卡死
18:50 整机僵尸态（部分进程存活但系统不可用），直至强制断电
```

## 五、排除项（已逐一核实，确认非故障源）

| 怀疑项 | 结论 |
| --- | --- |
| 硬盘故障 | 4× HDD + NVMe **SMART 全部 PASSED**，Reallocated/Pending/Offline_Uncorrectable 全 0 |
| 文件系统 | Volume1/Volume2 的 Btrfs `write/read/flush/corruption/generation io_errs` 全 0 |
| 内存条硬件 | 无 ECC 错误记录；开机 `EDAC igen6 HANDLING IBECC MEMORY ERROR` 为驱动固定误报（每次开机同地址 `0x7fffffffe0`） |
| OOM | 日志无 OOM Killer、无内存耗尽迹象 |
| 磁盘 IO 错误 | 无任何设备 I/O error、reset、timeout 记录 |

## 六、影响与恢复

- 死机导致**非正常关机**（脏关机）：RAID5（无 write-intent bitmap）开机后触发**全量重建，耗时约 10.7 小时**，期间整机磁盘性能大幅下降。
- 三个绑定精确宿主机 IP 的容器启动失败（`cannot assign requested address`），其余业务短暂不可用。
- 未发生数据损坏（Btrfs 错误计数 0）。

## 七、复现信息

1. 在 NAS 上以 Docker 运行 immich-server，对 HEVC/H.265 视频启用 QSV 硬件转码（`ffmpeg -hwaccel qsv -c:v hevc_qsv` 解码 + `h264_qsv`/`hevc_qsv` 编码）。
2. 持续提交多个转码任务（多路并发或连续 HEVC 解码）。
3. 观察内核 oops 出现（本次为转码开始后约 20 分钟内出现首个 oops）。

## 八、请求厂商协助的事项

1. **确认并修复 i915/QSV 驱动内存管理缺陷**：oops 上下文指向 i915 驱动在 QSV DMA/scatter-gather 缓冲生命周期管理上的 use-after-free / double-free（`sg_kmalloc` → `__kmalloc` 崩溃）。请核对 TOS 定制内核 6.12.63+ 的 i915 移植/补丁是否存在缺陷，或与上游 6.12.x stable 对比。
2. 若暂无法修复，请提供**临时规避方案**（如禁用 QSV/硬件转码的受控手段、可用的驱动参数）。
3. 请检查 `Tainted: G D OE` 中 TerraMaster 自有 OOT 模块（`scst*`、`tmacl_vfs`、`blk_uevent`、`8812au`、`88x2bu` 等）是否可能与 i915 路径存在内存冲突。
4. 后续 TOS 升级时请明确说明 i915/QSV 相关修复项。

[TMzethar]

已记录您反馈的问题，感谢提供详细内核日志。我们将结合互联网同类案例（如 immich #30083）及公开信息进行核查。
可尝试以下临时规避方法：
使用 QSV 转码应用时，关闭“硬件解码”，仅保留 QSV 硬件编码（软件解码 + QSV 硬编在同类案例中表现稳定）；
转码高峰期留意 dmesg 日志，出现 i915/GPU hang 报错时及时停止批量任务；
您提到的 OOT 模块排查项也已纳入核查。
评估进展及后续 TOS 版本的相关内核修复，将在此帖同步。

[TMzethar]

在尽可能复原的环境下的多次尝试未能复现您提及的异常情况。我们会继续保持观察。