|
The NMI ("Non Maskable Interrupt") is a hardware-driven interrupt much like the PIC interrupts, but the NMI goes directly to the CPU, not via the PIC controller.
Luckily, you CAN'''can''' have control over the NMI -- otherwise you couldwould be in deep trouble.
The NMI is "turned on" (set high) by the memory module when a memory parity error occurs. ▼
You have to be careful about disabling the NMI and the PIC for extended periods of time: your system will hang unless it has a failsafe timer! (You've always got one, as long as you don't kill the [[PIT]] timer.) ▼
outb(0x70, inb(0x70)&0x7F); ▼
outb(0x70, inb(0x70)|0x80); ▼
==About==
''As posted by Brendan in [this|Forum:9490] thread:''
The following is based on my own research into chipsets (and some unfortunate guess-work to fill in the gaps), and shouldn't be considered "100% correct"...
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.
==Usage==
▲The NMI is "turned on" (set high) by the memory module when a memory parity error occurs.
▲You have to be careful about disabling the NMI and the PIC for extended periods of time: your system will hang unless it has a failsafe timer! (You've always got one, as long as you don't kill the [[PIT]] timer.)
===Comments===
:Is it really wise to turn off NMI? okay, if you get an NMI while you're switching from RealMode to ProtectedMode, you could get a [http://en.wikipedia.org/wiki/Triple_fault Triple Fault], which would reset the system, but isn't a system reset wished when content from memory is unreliable by that time ? -- Pype.
:Is there much you can do if an NMI occurs? I guess if you got the error while reading from something that was copied from a disk at some point in the past and not modified since then you could read it from the disk again and continue with the (hopefully) good copy, but if it's something that has changed or been created dynamically then you don't really have an easy way to recover other than essentially starting from scratch. -- TheKemp
▲ outb(0x70, inb(0x70)&0x7F);
:Of course, you're assuming that the kernel code hasn't been corrupted, if the kernel is damaged then you'll most likely triple fault anyway. The best course of action is probably to request the user perform a RAM diagnostic with ~MemTest or something (and hope you don't crash before you can get that far). Then again... Windows keeps a "Hardware Damaged" flag for every physical page of RAM, unfortunately this would mean aborting the program that was running when the NMI occured then checking each page the program was using at the time for what are basically "bad sectors" and flaging them so they aren't used again -- AR
:So if an NMI occurs you should assume it'll continue happening at that location in future rather than it being a freak occurrence? -- TheKemp
▲ outb(0x70, inb(0x70)|0x80);
:I'm not an engineer so I wouldn't know for certain, but I would be inclined to think that if an NMI occurs on a page when you retest the program that caused the original NMI then it would seem rather likely that the chip is faulty, I don't know if Windows persists the flags across reboots but I doubt it since AFAIK it's impossible to tell if the RAM has been replaced while the computer was off. If the NMI doesn't occur again while checking the pages then the fault isn't severe and could be written off, just if it is a persistent problem then the page should probably be disabled (in the interest of preventing random program crashes) -- AR
:Added Brendan's information from the forums, could probably do with being organised better but at least it's here for now. -- TheKemp
----
| 