[ | Suche | Alternativ Version | Frame Version ]
DNF98113
Primary (Secondary) interrupt controller detected a lost hardware
interrupt
Grob gesagt entsteht diese Meldung immer dann, wenn das anfragende Device
seinen Interrupt verliert, bevor der Interrupt-Controller ein OK von der CPU
bekommt.
Stehen Daten an, die das Interrupt-Device (z.B. eine Netzwerkkarte oder
der HD-Controller) versenden muß, so gibt dieses Device eine
Interrupt-Anfrage, einen Event, an den Interrupt-Controller PIC (Programmable
Interrupt Controller) weiter.
Der PIC sammelt alle Events. Die CPU wird ihre derzeitige Aufgabe so bald
als möglich zwischenspeichern und für diesen Service unterbrechen
und fragt die Unterbrechung beim PIC an. Findet nun der PIC die
Interrupt-Anfrage (EVENT) des Devices nicht mehr, erhalten wir einen
"....lost hardware interrupt".
In einem 16-Bit-Rechner werden 2 PIC's eingesetzt: Primary (Int. 0-7) und
Secondary = (Int. 8-15). Abhängig davon, welcher Interrupt verloren
geht, bekommen wir entweder "Primary controller..." oder
"Secondary ...".
Da das Interrupt-Device aber noch immer Daten zu versenden hat, wird es
eine erneute Anfrage an den PIC senden ...., der wiederum erfragt bei der CPU
einen Interrupt-Service ...., und so weiter ..., und so weiter. Damit
erklärt sich auch, warum die Meldung eines verlorenen Interrupt durchaus
mehrmals hintereinander am Monitor erscheinen kann.
Im nahen Zusammenhang steht auch die Meldung "Spurious hardware
interrupt XX detected", die bei Systemen mit Shared-Interupt vorkommen
kann.
Da im rechnerinternen Ablauf durchaus ein Int.-Request verloren geht, ist
nicht immer ein Fehler vorhanden. Sollte die Meldung jedoch öfter
erscheinen und der Datendurchsatz erheblich verlangsamt werden, müssen
wir auf Ursachenforschung gehen.
Warum kann eine Interrupt-Anfrage verloren gehen?
- Durch eine unsaubere Interruptleitung der eingesetzten
FileServerhardware (Rechner).
- Kommen erneut Daten an das Device zur Abgabe, kann es sein, daß
auch eine erneute Interrupt-Anfrage erzeugt wird. Hierdurch können
"Glitches" auf der IRQ-Leitung entstehen. Als "Glitches"
bezeichnet man generell unsaubere Pegelzustände (LOW-HIGH Sprünge).
Dies wiederum kann zur Auswirkung haben, daß der PIC den Interrupt
nicht mehr lokalisieren kann.
- Sie besitzen Device-Treiber, die die Interrupt-Anfrage fehlerhaft
handhaben oder sogar stören.
- Die eingesetzte Hardware arbeitet mit den Devicetreibern in Bezug auf
diese Interruptanfragen nicht sauber zusammen.
Lösungsmöglichkeiten:
- Der Fehler wird bei den Netzwerkkarten lokalisiert:
Kontrollieren Sie, ob die neuesten Treiber eingesetzt werden. Vielleicht
setzen Sie testweise mal eine Karte eines anderen Herstellers ein.
- Der Fehler wird am Plattenkanal lokalisiert:
Hier zeigt die Erfahrung das insbesondere AT-Bus-Platten und deren
Controller mit diesem Problem zu kämpfen haben. Testen Sie beide Treiber
für die AT-Bus-Plattenkontroller (ISADISK und IDEDISK) der NetWare.
- In einem Fall lag es schlicht daran, daß das Kabel zwischen
Multi-IO- Karte und Festplatte zu lang war. Nach einer Verkürzung war
alles ok.
- Hilft das alles nichts, testen Sie an einem Rechner verschiedene
AT-Bus-Platten, Kabel und Controller.
- Kontrollieren Sie die Geschwindigkeit des Taktes auf dem Rechnerbus.
Eventuell können Sie diesen Bustakt runtersetzen oder auch Waitstates
einschalten.
- Sie bekommen relativ selten diese Meldung und Ihr Netzwerk arbeitet als
solches einwandfrei. Dann übersehen Sie zunächst einfach diese
Meldung und schalten diese mit set display lost interrupt alerts = off
und mit set display spurious interrupt alerts = off an der
Console aus, damit sie nicht mehr angezeigt werden. Beachten Sie jedoch,
daß diese Meldungen trotzdem noch in der ERROR-LOG-Datei mitgeschrieben
werden.
Copyright © by Stefan Braunstein (stefan@braunstein.de)
Letzte Aktualisierung am 1. November 1998
Zugriffe