我看到内核检查 CPU 时不时会提到这一点。我猜想这是与 HLT 指令相关的某种 CPU 硬件错误，但我找不到有关此问题的任何信息。那么 hlt_bug 到底是什么？
答案1
我不确定具体的细节，因为这是一个很久以前的问题，可能可以追溯到 386 型机器普及的时候。
HLT 指令只能在 CPU 未处于“实”模式时在“ring 0”中调用，因此它只能由现代操作系统中的内核调用。它指示处理器暂停，直到收到下一个中断。此时现代 CPU 将进入低功耗状态，但显然它不像多核 CPU 那么简单。
如果我没记错的话，这个错误是某些 386 CPU 在某些情况下不会响应某些中断而唤醒。检查是否存在此错误是通过设置一个受影响的 CPU 已知会响应的计时器和一个它们不会响应的计时器来完成的 - 如果 CPU 第一次唤醒是响应第一个较长周期的计时器，您就知道存在错误，因为它应该已经提前唤醒并服务于另一个较短周期的计时器的中断。由于 HLT 指令通常永远不会在内核之外调用，因此您不必担心它 - 我认为“hlt bug found”标志的唯一影响是停止调用 HLT 的电源管理代码，以使有错误因此可能不会唤醒的空闲处理器。
我在网上找到的关于这个错误的唯一参考资料（除了内核启动输出的副本、bugs.* 源文件和这个问题之外）（哇，这些网站上的问题进入了 Google 的数据库快速地！)) 经过快速搜索后，讨论了是否需要在内核中保留对它的检查，因为它不太可能影响人们现在正在使用或将来将要使用的任何硬件配置。
编辑： 本指南列出了某些 486DX-100 芯片中的 HLT 问题（搜索该页面以no-hlt获取参考）。这可能是我记得的问题（而不是某些 386 芯片的问题），也可能是巧合，并且存在两个与该指令有关的低功耗状态唤醒错误。
答案2
我遇到过一个！
我的第一台电脑是苏联的 Iskra EVM（基本上是一台 IBM PC/XT，带有 Iron Curtain 自己的总线，但完全兼容软件）。在极少数情况下，它会死机，有时会在屏幕上产生垃圾。经过仔细调查，我发现：
该系统配备有运行频率为 8 Mhz 的西门子 SAB 8086 CPU。
罪魁祸首是 HLT（0xF4）指令，无论中断被禁用还是启用，它都会终止系统。
一个简单的序列，如 0xFA、0xF4、0xC3（cli、hlt、ret）不会像人们预料的那样正常地冻结系统，而是在屏幕上产生垃圾，然后冻结。
类似的序列 0xFB、0xF4、0xC3（sti、hlt、ret）并没有悄悄地执行并返回到 shell，而是再次在屏幕上出现垃圾信息，然后要么冻结，要么（很少）返回 shell。
仅 0xF4、0xC3（无论如何，通常中断已启用） - 相同的垃圾、蜂鸣声和挂起。
我从来没有想过控制权被转移到哪里，我本可以编写一个引导加载程序，用钩子 (0xCC) 填充内存，然后 INT 03h 处理程序会告诉我它来自哪里。但那时我从未想过。或者也许它不仅仅是转移控制权，而是在某个地方破坏了一些东西，谁知道呢？我从未听说过西门子 CPU 上有缺陷的 HLT 指令，但情况可能就是这样。我不想一概而论，很可能只是这一个案例，或者可能是一批有缺陷的批次。
好了，故事讲完了——当时我发现了另一台相同型号的机器，但里面装有苏联的石头（KM1810VM86M——忠实地偷来（借来）然后复制的英特尔 8086 CPU）。我试着在那里玩 HLT 指令，它按应有的方式工作，就像英特尔 8086 程序员参考中所说的那样……
多么讽刺...多么精彩的故事！:)