linux-l: NMI received ...

[Marco Tidow]

(26 Sep 97:Oliver Bandel <linux-l at mlists.in-berlin.de>:)

>
>Hi!
>
>On Thu, 25 Sep 1997, Christoph Lange wrote:
>
>> 
>> Hallo, Leute!
>> 
>> Ich habe da mal wieder ein garstiges Problem: Ich bekomme von einem
>> 486dx50, auf dem ich Linux installieren will folgende Meldung beim
>> Booten, kurz bevor der Kernel panict: NMI received usw.
>> 
>> Was ist NMI? Was kann falsch sein?
>
>NMI heißt: Non Maskable Interrupt, also: nicht-maskierbarer Interrupt.
>
>Das ist ein interrupt, der z.B. 
> von Peripherie-Geräten, 
Steckkarten im (ISA-) bus: Speichererweiterungskarten mit parity Logik,
Alt-Grafikkarten (VGA,EGA) benutzen ihn als Hintertuer zum Modewechsel, (das
Realmode-ROM der Grafikkarte biegt die Register der Karte nach direkten 
Portzugriffen seitens der Applikationssoftware zurecht, auf diesen Karten 
ist i.d.R. ein Jumper zum Deaktivieren des NMIs vorhanden)

>dem Reset-Taster
no. jedenfalls nicht in 100%igen Nachbauten

>oder den Speicherbausteinen gegeben wird.
der parity-check Logik des mainboards

>Der ist nicht-maskierbar, weil er sehr hohe Priorität hat und
>normalerweise auf arge Funktionsstörungen hinweist. Die
>Nicht-Maskierbarkeit bedeutet: Man kann diesen Interrupt nicht per
>Software ausblenden/inaktivieren.
in der NMI-Leitung zum Intelprozessor sitzen bei kompatiblen ein paar
Gatter.  Ueber sie kann per Registerbit 7 der IO-Adr. 0x70 der NMI
hardware-seitig "maskiert" werden

>> Es schein ein Speicherproblem zu sein,
>
>> ich habe alte SIMMS, 4MB in
>> Bank0 und 16MB in Bank1. Der Computer findet's gut, keine Probleme mit
>> dem Memory-Check, aber Linux ...
>
>Der NMI sollte eigentlich per Hardware gesendet werden (Paritäts-Prüfung
>der Speicher-Bits). Das sollte zwischen Linux und anderer Software kein
>Unterschied bestehen.
Doch.  Folgender Fall:
ein 25MHz 486er board mit altem ISA-Opti chipset spielte jahrelang unter
WfW3.11 ohne Macken als 24h-Dauerlaeufer (das gibt's :-).

Booten der SuSe 4.4.1 Installationskernel (2.0.29) von Diskette ging auch.  
Beim boot von der IDE-Platte produzierte derselbe kernel NMI's und die Kiste 
hing. Der Speicher-refresh-timeout-counter lief ab und produzierte den 
parity-NMI. Der Fehler steckte im bus-timing-setup des chipsets.
(Meine Vermutung: IO/DMA-Zugriffe auf den floppy controller blockierten die 
bus-Logik, weil ein extended IO-ready Modus im CMOS-Setup aktiviert war, und
der chipset macht seinen RAM refresh noch per DMA Kanal nach Alt-IBM-Vaeter
Sitte)

Der Unterschied zu Linux ist wohl, das im Ggs. zu WfW einiges mehr 
nebeneinanderher passiert, statt traege nacheinander.

Marco