我看到它在内核检查CPU时不时提到。 我想这是与HLT指令有关的某种硬件问题，但我找不到任何有关这方面的信息。 那么实际上hlt_bug是什么？
我不清楚确切的细节，因为这是一个很久以前的问题，可能早在386机器普遍。
HLT指令只能在CPU处于“真实”模式时才能在“ring 0”中调用，所以只能在现代操作系统中由内核调用。 它指示处理器暂停，直到接收到下一个中断为止。 现代CPU在这个时候会进入低功耗状态，不过对于多核处理器来说显然不是那么简单。
如果我没有记错的话，那么错误的是，在某些情况下，有些386 CPU不会响应某些中断而被唤醒。 检查这个bug是否存在是通过设置一个定时器来完成的，这个定时器是已知响应的CPU，而不是 – 如果第一次CPU唤醒是为了响应第一个更长的时间段，知道存在的错误，因为它应该已经事先唤醒和服务其他，更短的时间，定时器的中断。 由于HLT指令通常不会在内核之外被调用，所以您不必担心 – 我认为“hlt bug found”标志的唯一影响是停止将电源pipe理代码调用HLT给具有该错误的空闲处理器所以可能不会醒来。
除了内核启动输出的副本，bug。*源文件和这个问题（哇，这些网站上的问题快速searchGoogle数据库！）之外，我在网上发现了这个bug的唯一参考）讨论是否需要在内核中保留它的检查，因为它不太可能影响到目前人们正在使用或将来要使用的任何硬件configuration。
编辑： 这个HOWTO在一些486DX-100芯片中列出了一个HLT问题（search该页面的no-hlt作为参考）。 这可能是我记忆中的问题（而不是386芯片的问题），也可能是巧合，并且有两个关于该指令的低功耗状态唤醒错误。
我遇到过一个！
我的第一台电脑是一个苏联的ISKRA EVM（基本上是一个带有Iron Curtain自己的总线的IBM PC / XT，但是完全是软件兼容的）。 在一些罕见的情况下，它是冻结的，有时在屏幕上产生垃圾。 经过仔细调查，我发现：
该系统有一个8 Mhz的西门子SAB 8086 CPU。
罪魁祸首是HLT（0xF4）指令，无论中断是被禁用还是被启用，都会导致系统死机。
一个简单的序列，如0xFA，0xF4，0xC3（cli，hlt，ret），并不像所期望的那样正常地冻结系统，而是在屏幕上产生垃圾，然后冻结。
类似的序列0xFB，0xF4，0xC3（sti，hlt，ret）不只是安静地执行并返回到shell，再次 – 垃圾屏幕，以及冻结或（很less）返回壳。
只是0xF4，0xC3（通常中断被启用，无论如何） – 相同的垃圾，哔哔声和挂起。
我从来没有想过控制权被转移到哪里，我可以写一个引导程序加载程序，用钩子（0xCC）填充内存，然后INT 03h处理程序会告诉我它来自哪里。 但是当时我从来没有想过这件事。 或者，也许这不仅仅是转移控制权，而是腐蚀某个地方，谁知道呢？ 我从来没有听说过西门子CPU上有问题的HLT指令，但情况可能如此。 我不想概括，它可能只是这一个案件，或者也许是一个越野车批次。
那么，为了完成这个故事 – 当时我发现了另外一台相同型号的机器，但里面有一台苏联石（KM1810VM86M – 忠实地被盗（借用），然后再生产了Intel 8086 CPU）。 我尝试了在那里使用HLT指令，IT按照它应该的方式工作，以及Intel 8086程序员参考说的方式。
多么具有讽刺意味的是，这真是一个故事！ 🙂