NMI(非屏蔽中断) DELL iDRAC

NMI全名Non Maskable Interrupt，在DSP等学习中解释为“不可屏蔽中断”。

戴尔 iDRAC重启选择出现NMI(非屏蔽中断)，不知其用途故作此笔记。

说人话：NMI(非屏蔽中断)通常要提前设置在crash dump目录，当发生硬件故障时，使用该重启方法会将crash dump文件保存下来以供硬件厂商分析故障原因。

• Crash dump具有崩溃转储、故障转储、系统崩溃后的内存倾倒等意思。

一、什么是NMI(非屏蔽中断)

来源：https://wiki.osdev.org/Non_Maskable_Interrupt
NMI occur for RAM errors and unrecoverable hardware problems. For newer computers these things may be handled using machine check exceptions and/or SMI. For the newest chipsets (at least for Intel) there’s also a pile of TCO stuff (“total cost of ownership”) that is tied into it all (with a special “TCO IRQ” and connections to SMI/SMM, etc). Somehow all of the TCO stuff is/can be connected to an onboard ethernet controller, and (at least part of it) is intended for remote monitoring of the system. Unfortunately the chipset documentation I’ve been reading can’t tell me how BIOSs normally configure the chipset, and the chipsets themselves support several different options in each case. For example, for a RAM error it could be handled by the chipset itself, it could generate an SMI (where the BIOS/SMM handler does “RAM scrubbing” in software), it could generate a “TCO interrupt”, etc. If you add it all up it’s a huge complex mess (TCO + SMI + SMBus + northbridge + PCI bus/controller/s + PCI-to-LPC-bridge + god-knows-what) that can be completely different between motherboards (even motherboards with the same chipset).

The short version of this story is that there’s only really 2 reasons for an NMI. The first reason is a hardware failure. The second reason is a “watchdog timer”, which can be used to detect when the kernel itself locks up (and is sometimes also used for more accurate profiling as it allows EIP to be sampled even when IRQs are disabled).

If a hardware failure caused an NMI then there’s no way to figure out which piece of hardware caused the NMI. In this case I’d try to do the least possible in an attempt to tell the user that a hardware failure occurred, but at the end of the day you can’t expect any OS to work sanely on faulty hardware and there’s nothing software can do to work around the hardware failure anyway.

For the watchdog timer, it must be setup by the OS first. This can actually be done even when the chipset itself doesn’t have a special watchdog timer for it (e.g. setting the PIT, RTC/CMOS IRQ or a HPET IRQ to “NMI, send to all CPUs” in the I/O APIC). In this case you want the watchdog timer to be fast (i.e. no slow hardware task switching and cache flushing) and you’d also want all CPUs to share the same timer, which means all CPUs would receive the same IRQ at the same time (which brings me back to the busy flag in your TSS).

As an alternative, you could also use the local APIC’s timer or the performance monitoring counter overflow for a “per CPU” watchdog timer. Unfortunately these things are usually used for other purposes.

• 翻译：NMI发生在RAM错误和不可恢复的硬件问题上…

二、NMI在Linux的应用

当系统挂起，失去响应的时候，可以人工触发NMI，使系统重置，如果早已配置好了kdump，那么会保存crash dump以供分析。有的服务器提供了NMI按钮，而刀片服务器通常不提供按钮，但可以用iLO命令触发。

Linux还提供一种称为”NMI watchdog“的机制，用于检测系统是否失去响应（也称为lockup），可以配置为在发生lockup时自动触发panic。

原理是周期性地生成NMI，由NMI handler检查hrtimer中断的发生次数，如果一定时间内这个数字停顿了，表示系统失去了响应，于是调用panic例程。
NMI watchdog的开关是通过内核参数 kernel.nmi_watchdog 或者在boot parameter中加入”nmi_watchdog=1″参数实现，比如：在RHEL上编辑 /boot/grub/menu.lst

• Linux kernel笼统地把NMI分为三大类：内存校验错 mem_parity_error()，总线数据损坏 io_check_error()，其他的全部归入 unknown_nmi_error()