8745HS飞牛：AMD 平台 ACPI 问题修复+ 人脸识别 ROCm GPU 实测

背景

Acer E10 用的是一颗 8745HS（Zen4 8 核 16 线程，RDNA3 Radeon 780M 核显，本质和 8845HS 同架构）。这台机器一度被我判为"跑不了 Linux，只能当纯 Windows 机"——因为装 Linux 后系统会莫名卡死。后来挖到底才发现，这个定论是我自己下错的：真相不是某台机器的孤例，而是 AMD 平台在 Linux 下的一个常见问题。把根因认清之后，三层固化就能稳定跑起来，还顺手验证了相册 AI 的 ROCm GPU 加速，目前已经是一台稳定的 Linux 开发机 + 相册 AI 加速节点。

本文记录完整的排查过程、根因、同类案例与三层固化修复，给遇到同类问题的朋友一个参考。

问题现象

系统运行几分钟到几小时后，突然完全卡死：

load average 飙到 2000+
kworker 出现 2050 个 D 状态（不可中断睡眠） 进程，全部卡死
SSH 连不上、界面无响应，只能断电重启

一开始以为是内存、驱动或内核问题，直到抓取 ACPI 中断日志才看到真凶。

根因：AMD 平台常见问题——GPE 风暴 + ACPI 方法重入上限

机器卡死的本质是一个 ACPI 电源事件风暴：

系统不断触发 gpe05 事件，中断风暴频率高达 ~1900 次/秒
每次触发都会去读 EC（Embedded Controller，嵌入式控制器）的 ADP1（AC 适配器）节点
最终踩爆 ACPI 方法重入上限，内核报错：

ACPI Error: Method reached maximum reentrancy limit (255) [_SB_.PCI0.SBRG.H_EC.ADP1], AE_AML_METHOD_LIMIT

这个 255 是 ACPICA（Linux 的 ACPI 实现）的保护机制：每个 AML 方法最多允许 255 层并发/重入执行，超限就报 AE_AML_METHOD_LIMIT。正常情况下不会踩到，但当 GPE 风暴把同一个 EC 方法疯狂排进内核工作队列，几秒内就能溢出上限——方法执行失败、EC 事务挂起，D 状态进程越积越多，最终系统瘫痪。

AMD 平台特别容易踩这个坑：AMD 固件把电池、温控、屏幕、键盘事件大量走 EC 的 _Qxx/_Lxx/_Exx 方法，只要固件里某个事件位没被正确消费，同一 GPE 就会反复触发，风暴随之而来。这不是 Acer E10 特例，Ryzen 笔记本上同类问题记录非常多（见下节案例）。

我这台上实测有两条触发路径：

路径 1：gpe05 中断风暴本身就会触发死锁（首次发现）
路径 2：加载 ac/battery 内核模块时，内核会读 EC 的 ADP1，同样立刻触发死锁（解开 blacklist 后重启即再卡死）

Windows 下一切正常——因为 Windows 的 EC 驱动栈不会去读这个有问题的 AML 路径。这不是内核的错，是固件的问题，Linux 侧没有纯软件修法，只能阻断对问题方法的访问。

同类案例（AMD 平台 Linux 下高频出现）

这个「EC/GPE 风暴 → 溢出 255 重入上限 → kworker 打满 / D 状态 / 高负载」的链路，在 AMD 笔记本上是知名的一类问题：

bugzilla.kernel.org #219055（Ubuntu #2073538）：AMD Ryzen 笔记本（HP Victus 15 / Ryzen 7 8645HS）kworker + ACPI 中断打满单核、load 飙高，与 EC GPE 交互相关；社区临时方案是 blacklist ucsi_acpi
bugzilla.kernel.org #218557：AMD 平台 suspend/resume 后 EC GPE 处理回归，CPU 被锁到 ~544MHz（Lenovo P16v/P15v Gen3、HP EliteBook 845 G10），内核有 DMI 定向补丁
bugzilla.kernel.org #53071：经典 GPE 中断风暴（GPE13），kworker 100% 打满 CPU
Framework 社区跟踪帖：AMD 机型 suspend/resume 后小群 kworker 持续占 CPU0，接扩展坞（USB-C/ucsi_acpi）触发 GPE 风暴
Fujitsu A544（Launchpad #1491467）：GPE13 风暴 kworker 吃满 CPU，需 BIOS 更新修复
内核历史同类修复：2005 年 ThinkPad 电池 _BIF 踩到 255 上限（ACPICA 线程计数 underflow bug，修复于 ACPICA 20051117）；2016 年 EC _Qxx 并行评估超 255 回归（内核补丁 e1191bd4f62d 加独立 EC 工作队列并限制并发）

共同点：固件/EC 事件没被正确消费 → GPE 风暴 → 溢出 255 重入上限 → kworker/D 状态/高负载。内核官方为此提供两类标准手段，正是下面方案用到的：

运行时 mask：echo mask > /sys/firmware/acpi/interrupts/gpeNN
开机 mask：内核参数 acpi_mask_gpe=0xNN

修复方案：三层阻断，全部实测生效

第一层：GRUB 内核参数

在 /etc/default/grub 里，把 ac、battery 两个电源模块列入内核 blacklist，并 mask 掉 gpe05：

GRUB_CMDLINE_LINUX="modprobe.blacklist=pcspkr,ac,battery pcie_aspm=off acpi_mask_gpe=0x05"

改完 update-grub 生效。

第二层：modprobe 兜底

/etc/modprobe.d/blacklist-acpi-pwr.conf：

# AMD EC firmware bug: ADP1 AML reentrancy lockup (AE_AML_METHOD_LIMIT) blacklist ac blacklist battery

第三层：systemd 服务兜底

GRUB 参数只在开机生效，为防中途状态被重置，再挂一个 oneshot 服务，开机后主动禁用 gpe05：

[Unit] After=multi-user.target [Service] Type=oneshot ExecStart=/bin/sh -c 'echo disable > /sys/firmware/acpi/interrupts/gpe05 || true' [Install] WantedBy=multi-user.target

三层层层兜底，即使某层失效也不至于卡死。

验证结果

重启后一切恢复正常：

load average 回到 0.78
gpe05 中断计数冻结不再增长
D 状态进程 0
SSH 长期稳定

代价：Linux 下电池/电源管理不可用

阻断对问题 EC 节点的访问，代价就是 ac/battery 两个模块被禁，Linux 下电池状态、电源管理功能不可用（插拔电源的系统提示、电量显示都没了）。但换来的是稳定可用。如果以后主板更新了 BIOS/EC 固件修复事件消费问题，或新内核不再触发，再解开即可。

恢复路径备忘：若误解开后卡死，物理重启 → GRUB 菜单按 e → 把 modprobe.blacklist=pcspkr 改成 modprobe.blacklist=pcspkr,ac,battery → Ctrl+X 进系统再持久化。

后续：相册人脸识别 ROCm GPU 加速实测

机器修稳之后，装上 ROCm 7.2 + MIGraphX，跑飞牛相册的人脸识别任务，GPU 有明确占用、识别速度相比 CPU 明显加速。这是 RDNA3 780M 核显在飞牛相册 AI 上的一次真实可用验证（此前一般认为 AMD 核显跑相册 AI"非开箱即用"，这台实测是可行的）。

下图是人脸识别运行时的 GPU / CPU 占用与任务进度实拍：

8745HS飞牛：AMD 平台 ACPI 问题修复+ 人脸识别 ROCm GPU 实测

总结

这台机器"跑不了 Linux"的定论是我自己下错的：真相是 AMD 平台 Linux 下的常见问题（EC/GPE 风暴 + ACPI 方法重入上限），不是 Acer E10 特例，Ryzen 笔记本同类案例一大把
修法：三层阻断（GRUB blacklist + acpi_mask_gpe=0x05 + modprobe + systemd 兜底），实测稳定；mask 风暴 GPE 是内核官方推荐的标准手段
代价：Linux 下电池/电源管理不可用（根源在固件不消费事件，等 BIOS/EC 更新或新内核）
修好后：相册人脸识别 ROCm GPU 加速实测通过，开发机 + AI 加速双用成立

作者声明本文无利益相关，欢迎值友理性交流，和谐讨论～