ymajoros Asked: 2020-09-17 23:52:40 +0800 CST2020-09-17 23:52:40 +0800 CST 2020-09-17 23:52:40 +0800 CST acpi 事件 69 使我的系统无法使用 772 几天前，cat /sys/firmware/acpi/interrupts/gpe69数以百万计，我的系统无法使用。禁用后一切正常。 有没有办法知道 ACPI 事件 69 是关于什么的？ acpi 2 个回答 Voted Best Answer Paolo 2021-08-13T22:43:06+08:002021-08-13T22:43:06+08:00 我有同样的问题。我反汇编了 ACPI 表，它似乎是来自连接到根端口的 PCI 设备的唤醒请求（即 PCI 地址 1b.0-1b.7、1c.0-1c.7、1d.0-1d.7） . 在我的例子中，它是 NIC、NVMe 磁盘和 Thunderbolt 扩展坞；我的钱会花在后者上，因为有时在使用扩展坞后我会遇到暂停问题。 LeonM 2021-11-04T10:46:54+08:002021-11-04T10:46:54+08:00 我知道这是一个老话题，但是当联想 Thunderbolt TB3 坞站（gen-2 40AN）时，我的联想笔记本电脑上遇到了完全相同的问题。也许我的发现可以帮助其他人。 每当连接到 TB 扩展坞的屏幕进入待机状态时，风扇就会加速，kworker/kacpi 开始占用 70% 的 CPU，从而使风扇一路加速。 我在屏幕处于待机状态时通过 SSH 连接到系统（风扇疯狂地吹着）。看着grep . -r /sys/firmware/acpi/interrupts/我可以看到acpi/interrupts/gpe69被触发了数百万次。 为了验证我的怀疑，我在运行时禁用了中断： echo "disable" | sudo tee /sys/firmware/acpi/interrupts/gpe69 这有帮助，负载降至 0，风扇逐渐减少。然后我直接测试了系统（不是通过 SSH），一切似乎仍然运行顺利，甚至可能像以前一样响应更快。 为了在启动时禁用中断，我更新了我的 grub 配置： GRUB_CMDLINE_LINUX_DEFAULT="acpi_mask_gpe=0x69 quiet splash" 我仍然不确定 gpe69 究竟做了什么，但在我的情况下，禁用中断使我的系统安静，并且响应更快。
我有同样的问题。我反汇编了 ACPI 表，它似乎是来自连接到根端口的 PCI 设备的唤醒请求（即 PCI 地址 1b.0-1b.7、1c.0-1c.7、1d.0-1d.7） .
在我的例子中，它是 NIC、NVMe 磁盘和 Thunderbolt 扩展坞；我的钱会花在后者上，因为有时在使用扩展坞后我会遇到暂停问题。
我知道这是一个老话题，但是当联想 Thunderbolt TB3 坞站（gen-2 40AN）时，我的联想笔记本电脑上遇到了完全相同的问题。也许我的发现可以帮助其他人。
每当连接到 TB 扩展坞的屏幕进入待机状态时，风扇就会加速，kworker/kacpi 开始占用 70% 的 CPU，从而使风扇一路加速。
我在屏幕处于待机状态时通过 SSH 连接到系统（风扇疯狂地吹着）。看着
grep . -r /sys/firmware/acpi/interrupts/我可以看到acpi/interrupts/gpe69被触发了数百万次。为了验证我的怀疑，我在运行时禁用了中断：
这有帮助，负载降至 0，风扇逐渐减少。然后我直接测试了系统（不是通过 SSH），一切似乎仍然运行顺利，甚至可能像以前一样响应更快。
为了在启动时禁用中断，我更新了我的 grub 配置：
我仍然不确定 gpe69 究竟做了什么，但在我的情况下，禁用中断使我的系统安静，并且响应更快。