什么是 hlt_bug？

Question

当内核检查 CPU 时，我不时看到它被提及。我想这是与 HLT 指令相关的某种 CPU 硬件错误，但我找不到任何关于此的信息。那么什么是hlt_bug呢？

Answer 1

我不确定确切的细节，因为这是很久以前的问题，可能早在基于 386 的机器很普遍的时候。

HLT 指令只能在 CPU 不处于“真实”模式时在“ring 0”中调用，因此它只能由现代操作系统中的内核调用。它指示处理器暂停，直到接收到下一个中​​断。现代 CPU 在这一点上会进入低功耗状态，尽管这显然不像多核 CPU 那样简单。

如果我没记错的话，错误是某些 386 个 CPU 在某些情况下不会响应某些中断而唤醒。检查是否存在此错误是通过设置一个计时器来完成的，受影响的 CPU 已知会响应该计时器，而不会响应该计时器 - 如果第一次 CPU 唤醒是响应第一个更长的时间段，则计时器您知道错误存在是因为它应该已经提前唤醒并服务于另一个更短的时间，计时器的中断。由于 HLT 指令通常不会在内核外部调用，因此您无需担心 - 我认为“hlt bug found”标志的唯一影响是停止调用 HLT 的电源管理代码到有 bug 的空闲处理器所以可能不会醒来。

我发现这个bug网上唯一的参考（除了内核引导输出，虫子的副本。*的源文件，而这个问题（哇，这些网站上的问题，打谷歌的数据库快！））后，快速搜索是一个现在讨论是否需要在内核中保留对它的检查，因为它不太可能影响人们今天使用或将来要使用的任何硬件配置。

编辑： 这个 HOWTO列出了一些 486DX-100 芯片中的 HLT 问题（搜索页面以no-hlt获取参考）。这可能是我记得的问题（而不是某些 386 芯片的问题），也可能是巧合，并且有两个关于该指令的从低功耗状态唤醒的错误。

Answer 2

我遇到了一个！

我的第一台计算机是苏联 Iskra EVM（基本上是带有 Iron Curtain 自己总线的 IBM PC/XT，但完全兼容软件）。在极少数情况下，它会冻结，有时会在屏幕上产生垃圾。经过仔细调查，我发现：

1. 该系统有一个以 8 Mhz 运行的 Siemens SAB 8086 CPU。

2. 罪魁祸首是 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 程序员参考所说的方式......

多么讽刺……多么美妙的故事！:)