Messages in this thread | | | Date | Thu, 4 Sep 2008 16:56:17 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH RFC] NMI Re-introduce un[set]_nmi_callback |
| |
* Prarit Bhargava <prarit@redhat.com> wrote:
>> Why is the DIE_NMIWATCHDOG notifier not sufficient for this driver? > > Peter -- good question. The HP systems with this HW will use the > hpwdt driver in place of the default nmi watchdog. When the HW > detects a problem, the HW will generate a single NMI that the driver > will handle. The driver doesn't want the NMI to be rejected due to a > reason code. I'm sure that Thomas Mingarelli, who is cc'd, can > provide further details. > > From our quick conversation as well, you raised an interesting point > about oprofile, kgdb, and other subsystems that use the NMI notifier > chains -- they may be impacted by the NMI callback. > > Don (dzickus) or Aris, do you have any thoughts on how to get around > the second issue? We could check to see if anything is registered on > the notifier chain and the fail to register the callback.
i'd much rather attack this general problem from this angle:
static inline unsigned char get_nmi_reason(void) { return inb(0x61); }
that port 61H read is both arcane (on modern chipsets) and broken on multiple levels. It's racy and SMP unsafe to begin with, if there's any mixture of intentional cross-CPU or CPU self-generated NMIs mixed with chipset generated NMIs.
One possible approach would be to get rid of it, and to perhaps register a low-priority die notifier on systems where we know port 61 reads+writes to be safe and desired. Modern systems will emit MCEs in most cases anyway, not NMIs.
Ingo
| |