私は NetBSD で、NMI が私のボックスを DDB に置いたという状況に対処しています。NMI は、メモリ関連の問題が原因である可能性があることを理解しています。メモリがマップされているデバイスも同じシナリオにつながる可能性があると思います。これについて私を修正してください。
私の理解では、これらすべてのデバイスのステータスを、おそらく pci 経由で読み取る必要があるということです。
私はそれが何であるか、どのように知っているかわかりません。
NMI を受信すると、NetBSD を DDB デバッガーに置くトラップが生成されます。そこで DDB から何かを得ることは困難です。私の計画は、エラーがカーネル コア ダンプを引き起こすように、何もせずにトラップから戻ることです。また、トラップから戻る前に、必要なレジスタ/メモリを読み取って、関連するデバイスのステータスをダンプしたいと考えていました。これが私の行動計画です。それを行うためのより良い適切な方法があれば教えてください。
私の目的は、ここの専門家から理解し、NMI のソースにたどり着くための段階的な計画を立てることです。
Intel は、プラットフォーム レベルのエラー処理について、「 Intel システムのプラットフォーム レベルのエラー処理戦略」というタイトルの概要ドキュメントで説明しています。
そのドキュメントは、あなたが言及した Centerton (64 ビット Atom) を具体的にカバーしていません (ただし、Intel がハードウェア エラー報告をどのように考えているかについての概要を説明しています)。ただし、Centerton はシステム オン チップ デバイスであるため、デバイスのデータ シートからその動作について詳しく知ることができます。インテル Atom プロセッサー S1200 チップのデータシートのボリューム 1 には、次のテキストがあります。
内部ノンマスカブル割り込み (NMI) は、PCI Express ポートによって、およびロー ピン カウント インターフェイス信号 LPC_SERIRQ からの内部 IOCHK# 信号から内部的に生成できます。
また、Atom ベースのシステムで NMI を生成できる外部電源管理エラー信号ピンがあることもわかりました。
間違いなく、メモリ ハードウェアからのエラーも NMI の生成に関与している可能性があります。
S1220 データシートの第 2 巻には、エラー信号の処理に関連する多くのシステム レジスタに関する詳細が記載されています。
ただし、これはどれも NetBSD について多くを語っていません。ただし、NetBSD にはあまり期待できないと思います。ハードウェア エラーに関する詳細を解読するために実行される多くの x86 システムに関する十分な詳細な知識がありません。NetBSD DDB カーネル内デバッガーを介して十分な数のシステム レジスターにアクセスすることは可能かもしれませんが、これを手動で行うのは非常に面倒かもしれません。
システム BIOS がエラー レジスタを読み取って解釈できるかどうかを調べる方法がありますが、システムにボード管理コントローラーも搭載されていない限り (私の理解が正しければ、Atom システムではありそうにありません)、システムの記録が存在する可能性はほとんどありません。エラーは、BIOS がアクセスできる場所に保持されます。