在x86 Intel Centerton上获取NMI的来源

Question

我正在NetBSD处理一个情况，NMI将我的盒子放到了DDB上。 我知道NMI可能是由于一些与内存有关的问题。我想内存映射的设备也可能导致我进入相同的场景。请纠正我。

我的理解是我需要读取所有这些设备的状态，可能是通过pci。

我不知道它是什么以及如何。

在接收到NMI时，会生成一个陷阱，将NetBSD置于DDB调试器。从DDB那里获得任何东西都很困难。我的计划是从陷阱返回而不做任何事情，以便错误将导致内核核心转储。此外，在从陷阱返回之前，我想读取所需的寄存器/内存以转储所涉及设备的状态。这是我的行动计划。如果有更好和正确的方法，请告诉我。

我的目标是从这里的专家那里了解并提出一个逐步的计划来了解NMI的来源。

Answer 1

英特尔在标题为Platform-Level Error Handling Strategies for Intel Systems

的高级文档中描述了平台级错误处理

该文档并未具体涵盖您提到的Centerton（64位Atom）（但它确实对英特尔如何考虑硬件错误报告提供了一些很好的概述）。然而，由于Centerton是一个片上系统器件，我们可以从器件数据表中找到更多关于它如何工作的信息。在Intel Atom Processor S1200 chip datasheet的第一卷中，我们找到以下文字：

  

内部不可屏蔽中断（NMI）可由PCI Express端口生成，内部可通过低引脚数接口信号LPC_SERIRQ的内部IOCHK＃信号生成。

我们还发现外部电源管理错误信号引脚可以在基于Atom的系统中生成NMI。

毫无疑问，内存硬件的错误也可能导致生成NMI。

S1220 datasheet的第2卷提供了有关处理错误信号所涉及的许多系统寄存器的更多细节。

但这些都没有说明NetBSD。我不认为你对NetBSD的期望太高了。它没有足够详细的知识来运行它运行的许多x86系统来解码有关硬件错误的细节。可以通过NetBSD DDB内核调试器访问足够的系统寄存器，但我怀疑手动操作可能非常繁琐。

您可能会探索的一个途径是系统BIOS是否能够读取和解释错误寄存器，但除非您的系统还有一个电路板管理控制器（如果我理解正确的话，Atom系统不太可能），那么它就是＆＃39;不太可能有任何系统错误记录保存在BIOS可以访问它们的地方。

Answer 2

NMI - 非屏蔽中断通常由硬件监视程序引发，表示CPU挂起而不是由于无效的内存访问（至少在Mips / powerpc中，因为我对它们有一些了解）。无效的内存访问具有单独的异常/中断来处理。

CPU挂起的一种情况是由于死锁或某些类似的情况。 因此，采用coredump并检查每个核心在NMI时所做的事情应该是前进的一种方式。