3.10.6 lost hardware interrupts
DNF94658
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.
3.10.7 File Server mit > 16 MB RAM
| 