IRQ 15 sollte man bei NetWare Servern nicht verwenden, wenn es sich vermeiden läßt. Neben der banalen Erklärung, daß eventuell der zweite Port des EIDE-Controllers - auf neueren Computern direkt auf dem Motherboard - nicht (vollständig) deaktiviert wurde, gibt es eine recht komplexe Antwort von Novell unter der TID 10024783 (lokal), die diese Aussage etwas relativiert:

IRQ 7 und 15 belegen die jeweils hochwertigste IRQ Leitung der beiden IRQ Controller und fungieren als Platzhalter, wenn der Urheber eines IRQ Requests nicht gefunden wurde.

Daher stammen auch die Fehler der "Lost hardware interrupts", die bei der NetWare öfters auftauchen (können).

Geräte mit "edge triggered Interrupts" haben mit diesen "Lost Interrupts" erheblich mehr Probleme als solche, die mit "level triggered interrupts" arbeiten und auch IRQ-Sharing beherrschen. Deren Treiber sind nämlich "gewohnt", mit lost interrupts umzugehen.

In Versionen vor NetWare 4.11 gab es zusätzlich einen Bug, der einen reellen IRQ auf IRQ 7 oder 15 als "lost hardware interrupt" deklarierte und ihn einfach verwarf.

Diverse ISA Treiber mit "edge triggered interrupts" können nicht unterscheiden, ob es um einen lost interrupt oder einen reellen IRQ handelt, der für sie gedacht war, wenn sie mit IRQ 7 oder 15 betrieben werden und beantworten diesen auf gut Glück. Und das kann genau dann schief gehen, wenn es ein "Lost Interrupt" war.

Deshalb gilt die Empfehlung, IRQ 7 und IRQ 15 zu vermeiden, vor allem für Karten, die kein Interruptsharing beherrschen. Das sind vor allem ISA Karten, kann aber auch bei PCI Karten mit schlecht programmierten Treibern passieren.

Als Faustregel gilt: *.dsk Treiber können in der Mehrheit kein Interruptsharing, *.ham Treiber können es. Analoges gilt für *.lan Treiber, die nicht mit ODI3.31 arbeiten.