我长期以来一直习惯构建自己的内核（时不时地），使用仅带有 ConKolivas 补丁的库存源，使用 -O3 而不是 -O2 优化（我可以在其中进行设置），并针对 Core2 CPU 系列。该配置最初基于 Ubuntu 14.04 提供的最新内核之一；基本上我在那里停用的唯一内容是与 AppArmor、SELinux 和系列相关的设置。
我几年前构建的最新内核是 4.14.23 。它工作正常，在每天至少暂停一次的笔记本电脑上运行时间很长，但偶尔暂停程序会卡住，电源 LED 保持亮起，我需要重新启动机器。确切的症状已经报道过无数次了。
本周我升级到了 4.19.133（这是我开始构建和严格测试时的当前版本）。我最终升级了我的主要安装，认为我已经测试了所有内容，却发现挂起问题系统性地出现。
Devuan Beowulf（又名 Debian Buster）稍旧的 4.19.0-9 内核不受影响，但令人烦恼的是配置差异太多，无法找到关键差异。我在内核中尝试了相同的 XHCI 配置，但这没有帮助。
我还没有发现任何有关此特定内核版本的挂起问题的报告，因此我对当前版本（137）有修复不抱太大希望，但我们会看到的。
谁能给我一个真正的答案，这里可能会出现什么问题和/或我如何防止它？ YouTube 上有一个关于 5.x 内核修复的视频，我怀疑它对我有什么用处。
注意：我的主系统仍在 Kubuntu 14.04 上，我正在使用 Devuan Beowulf 设置第二个系统。换句话说，两者都是免费的。
答案1
我刚刚从 4.19.0-9 转到 4.19.0-10。我的电脑在 4.19.0-10 内核上停止从挂起正确唤醒。我必须使用电源按钮才能唤醒。在两者之间切换重新启动，我可以验证我的挂起问题仅发生在 4.19.0-10 版本中。我还没有在 SYSLOG 中发现任何真正的问题，尽管临时看起来工作系统还有更多的 ACPI 条目。也许这个小的版本差异可以帮助某人缩小问题范围。
答案2
我想我可能只是偶然发现了一些答案，或者至少是对使用 Con Kolivas (ck1) 补丁构建的内核的修复 - 对于 5.7 内核。它离线核心时不应调用 finish_cpu()。考虑到我所看到的症状，这实际上听起来像是一个非常合理的解释：如果finish_cpu()按照我认为的那样进行，则意味着有问题的 cpu 在调用该函数后无法再执行任何操作（并且我希望固件会执行等效的操作）在安全的情况下进行操作）。
-ck1内核的用户可以尝试应用提交muqss: Revert invocation of "finish_cpu" when offlining core。这实际上并没有恢复补丁所做的更改，因此或许该补丁也将或可以应用于库存内核。这非常简单。