Sporadischer Stop-Fehler IRQL_NOT_LESS_OR_EQUAL mit unklarer Ursache (lang)

09/02/2010 - 10:37 von Michael Landenberger | Report spam
Hallo,

da der folgende Bericht etwas lànglich ausfàllt, danke ich schon an dieser
Stelle für die Geduld beim Lesen.

Hier làuft ein kleiner, frisch aufgesetzter Heimserver unter Windows 2000
Professional, der u. A. mit folgender Hardware bestückt ist:

- Mainboard MSI-6380 (K7T266 Pro2-RU) mit Athlon XP 1600+
und 1,5 GB PC3200 RAM
- GraKa nVidia Riva TNT2 M64
- NoName SATA-PCI-Controller mit SiL3512 RAID
(mit 2 neuen WD Caviar Blue 500GB-Platten dran, von denen eine
die Bootplatte ist. IDE-Festplatten gibt es in dem Rechner nicht.
SATA RAID wird nicht genutzt)
- 3Com Fast Ethernet Netzwerkadapter 3C905CX

Von der Onboard-Peripherie des Mainboards sind folgende Komponenten aktiv:

- Primary IDE (mit DVD-Brenner als Master)
- Secondary IDE (mit ZIP-Laufwerk als Master)
- VIA Universeller USB-1.1-Hostcontroller
(benutzt für Maus und Tastatur)
- NEC Universeller USB-2.0-Hostcontroller
(benutzt für eine externe Festplatte, einen Drucker und
ein Multifunktionsgeràt)

Nicht benötigte Onboard-Komponenten wie z. B. COM, LPT, Sound + Gameport,
MIDI, Promise RAID Controller etc. habe ich im BIOS deaktiviert.

An speziellen Diensten làuft auf dem Rechner noch ein Apache Webserver und
ein UltraVNC Remote Desktop Server. Letzterer bringt noch eine virtuelle
Grafikkarte mit Namen "mv video hook driver" mit.

Nach einigen Anfangsschwierigkeiten mit der IRQ-Verteilung (siehe
<news:7t2actFsd6U1@mid.uni-berlin.de>), zu deren Behebung ich den PCI-Slot
#2 mit dem SATA-Controller zuerst auf IRQ 3 und jetzt auf IRQ 10 fest
eingestellt habe, lief das alles zunàchst zufriedenstellend. Ich habe,
nachdem alles lief, im BIOS noch die Speicheransteuerung etwas veràndert:
ich habe die SDRAM Commandrate von 2T auf 1T und die Burst Length von 4QW
auf 8QW umgestellt. Alle anderen Einstellungen entsprechen den BIOS
Defaults, mit Ausnahme des FSB-Takts, den ich passend zur CPU auf 133 MHz
umstellen musste (Default sind nur 100 MHz).

Nun zu meinem Problem:
Nachdem sich der Rechner zunàchst unauffàllig verhielt, gab es beim
Entpacken eines größeren, selbstentpackenden RAR-Archivs plötzlich einen
sporadischen Bluescreen mit IRQL_NOT_LESS_OR_EQUAL in ntoskrnl.exe. Die
angegebenen Adresswerte (> 0x80400000) konnte ich keinem Treiber zuordnen.
Also habe ich zunàchst defekten RAM als Ursache vermutet. Nachdem ich die
"verschàrften" RAM-Einstellungen rückgàngig gemacht hatte, war das Problem
zunàchst behoben. Trotzdem ließ ich einige Stunden lang Memtest86+ laufen.
Ergebnis: keine Fehler. Ein zweiter Test, diesmal wieder mit den
"verschàrften" RAM-Timingeinstellungen, hatte das gleiche Ergebnis. Da habe
ich vermutet, dass es nicht am RAM liegt, sondern an einer ungeeigneten
IRQ-Einstellung. Also habe ich im BIOS dem SATA-Controller einen anderen IRQ
zugewiesen (vorher: 3, nachher: 10). Nun trat der
IRQL_NOT_LESS_OR_EQUAL-Fehler nicht mehr auf, auch nicht mit der
RAM-Einstellung auf 1T/8QW. Allerdings verhàlt sich der Rechner jetzt in
anderer Hinsicht merkwürdig:
1. beim Entpacken des genannten RAR-Archivs wurde einmal ein CRC-Fehler
gemeldet. Bei weiteren Versuchen ließ sich das Archiv dann ohne
Fehlermeldung entpacken.
2. Kopiert man größere Datenmengen (200 MB) von einer der internen
SATA-Platten auf die externe USB-Platte, làuft der Kopiervorgang zwar
korrekt bis zum Ende durch. Danach friert der Rechner aber zunàchst einmal
für 15-20 Sekunden komplett ein. Nur den Mauszeiger kann man dann noch
bewegen. Tastatureingaben und Mausklicks werden dagegen ignoriert. Nach
15-20 Sekunden kann man dann normal weiterarbeiten.
3. Der UltraVNC Remote Desktop reagiert auf dem Remote-Rechner deutlich
zàher als vorher.
4. Gelegentlich taucht in der Taskleiste die Meldung auf "LAN-Kabel wurde
entfernt", obwohl das nicht der Fall ist. Der UltraVNC Client schließt sich
dann. Die Punkte 3 und 4 lassen mich ein Problem bei der Netzwerkverbindung
bzw. dem Netzwerkadapter vermuten.

In diesem Zustand erscheint mir der Rechner wenig vertrauenswürdig. Ich
wüsste daher gerne, wie ich die Hardware reibungslos zum Laufen bekomme.
Insbesondere beunruhigt mich, dass sich lt. Everest der NEC
USB-Hostcontroller und der SATA-Festplattencontroller einen IRQ (17) teilen.
Der IRQ 18 wird zwischen NEC USB-Controller und Netzwerkadapter geteilt. Ich
hàtte aber gerne, dass SATA-Controller und Netzwerkadapter jeweils einen
exklusiven IRQ zugewiesen bekommen, habe das aber noch nicht hinbekommen.
Oder liegt die Ursache für die beschriebenen Probleme woanders?

Gruß

Michael
 

Lesen sie die antworten

#1 Stephan Grossklass
09/02/2010 - 13:01 | Warnen spam
Michael Landenberger schrieb:

Insbesondere beunruhigt mich, dass sich lt. Everest der NEC
USB-Hostcontroller und der SATA-Festplattencontroller einen IRQ (17) teilen.
Der IRQ 18 wird zwischen NEC USB-Controller und Netzwerkadapter geteilt. Ich
hàtte aber gerne, dass SATA-Controller und Netzwerkadapter jeweils einen
exklusiven IRQ zugewiesen bekommen, habe das aber noch nicht hinbekommen.



Umstöpseln. Làßt sich das Boardhandbuch zur Verteilung der
PCI-INT-Leitungen aus?

KT266A... naja. Vor der VT8235-Southbridge war PCI bei VIA nicht so
prickelnd.

Stephan
Home: http://stephan.win31.de/

Topflappen verlegt?
Nimm's mit Humor.

Ähnliche fragen