我正在处理 NetBSD 上的一种情况，其中 NMI 已将我的盒子放入 DDB。我知道 NMI 可能是由于一些与内存相关的问题。我想内存映射的设备也可能导致我进入相同的场景。请就此纠正我。
我的理解是我需要读取所有这些设备的状态，可能是通过 pci。
我不知道它是什么以及如何。
在收到 NMI 时，会生成一个陷阱，将 NetBSD 放入 DDB 调试器。在那里很难从 DDB 获得任何东西。我的计划是不做任何事情就从陷阱中返回，这样错误就会导致内核核心转储。此外，在从陷阱返回之前，我想读取所需的寄存器/内存以转储所涉及设备的状态。这是我的行动计划。让我知道是否有更好和正确的方法来做到这一点。
我的目标是从这里的专家那里了解并提出一个逐步的计划来找到 NMI 的源头。
英特尔在题为“英特尔系统的平台级错误处理策略”的高级文档中描述了平台级错误处理
该文档并未具体涵盖您提到的Centerton（64位Atom）（但它确实很好地概述了英特尔如何看待硬件错误报告）。然而，由于 Centerton 是一种片上系统设备，我们可以从设备数据表中找到更多关于它如何工作的信息。在英特尔凌动处理器 S1200 芯片数据表的第一卷中，我们找到以下文本：
内部不可屏蔽中断 (NMI) 可以由 PCI Express 端口生成，也可以在内部由来自低引脚数接口信号 LPC_SERIRQ 的内部 IOCHK# 信号生成。
我们还发现，在基于 Atom 的系统中存在可以生成 NMI 的外部电源管理错误信号引脚。
毫无疑问，来自内存硬件的错误也可能是产生 NMI 的原因。
S1220 数据表的第 2 卷提供了有关处理错误信号所涉及的许多系统寄存器的更多详细信息。
不过，这些都没有说明 NetBSD。不过，我认为您不能对 NetBSD 抱有太多期望。它对运行在其上的许多 x86 系统没有足够的详细知识来解码有关硬件错误的细节。可以通过 NetBSD DDB 内核调试器访问足够多的系统寄存器，尽管我怀疑手动执行此操作可能非常乏味。
您可能会探索的一种途径是系统 BIOS 是否能够读取和解释错误寄存器，但除非您的系统还具有板管理控制器（如果我理解正确，不太可能用于 Atom 系统），那么不太可能有任何系统记录错误保存在 BIOS 可以访问它们的地方。
NMI - 不可屏蔽中断通常由硬件看门狗引发，以指示 CPU 挂起，而不是由于无效的内存访问（至少在 Mips/powerpc 中，因为我对它们有一些了解）。无效的内存访问需要处理单独的异常/中断。
CPU 挂起的情况之一是由于死锁或某些类似情况。因此，采用 coredump 并检查每个核心在 NMI 时正在做什么应该是前进的一种方式。