Probleme beim Drucken haben meistens drei Ursachen:

> CAPTURE - Anweisung:

Oft fehlen neben den erforderlichen Parametern noch weitere:
NT - Graphikausdrucke sehen jetzt wieder vernuenftig aus (Erklaerung RTFM)
NB - Dadurch wird der Ausdruck eines Deckblattes unterdrueckt.
NFF - Leerseiten, die evtl. jedes zweite Blatt erfolgen, werden unterdrueckt.
TI=10 - Der Ausdruck wird nach 10 Sek. ausgegeben (evtl. Wert anpassen) und nicht erst nach dem Verlassen des Programms.

Unter Windows oder anderen Programmen, die die parallele Schnittstelle nach dem Druck schliessen, ist allerdings TI=0 zu empfehlen, da der Ausdruck dann wirklich sofort nach dem Wegschicken kommt. (Testen!)

> alter Printserver:

bei der NW 3.11 UNBEDINGT einen neuen verwenden, z.B. den PSERVER 1.27, bei der NW 3.12 sollte man den Original Printserver auch austauschen. Auch die NW 4.0x hat schon einen neuen PSERVER.

> inkompatible parallele Schnittstelle:

"Billig"-Schnittstellen unterstuetzen den IRQ nicht ganz korrekt. Falls der Ausdruck am Server oder RPRINTER quaelend langsam ist, entweder auf Polling umschalten (am Server Use Interrupts=No, an der WS mit neuem RPRINTER) oder eine andere Schnittstellenkarte einbauen.

> loader cannot find public symbol .......

Viele Programme (NLMs) nutzen die Routinen, die von dem Modul CLIB.NLM zur Verfuegung gestellt werden. Da dieses Modul mit der Zeit immer wieder erweitert wird, verursachen Anwendungen, die diese neuen Routinen ansprechen wollen, obigen Fehler.

Abhilfe: die neueste CLIB.NLM benutzen.

Manchmal kann es auch daran liegen, dass NLMs fuer NW 4.x programmiert wurden. Diese Version hat neue Routinen, die aber bei der NW 3.11 und 3.12 ueber das Modul AFTER311.NLM zur Verfuegung gestellt werden. Dieses Modul muss bei manchen Programmen zuvor manuell geladen werden.

Beide NLMs sind in dem Novell-Patch LIBUP?.EXE enthalten.

Aktuell: Version CDUP2.* (enthaelt auch neue IDE-Treiber fuer Harddisk)

Das CDROM.NLM aus CDUP2 funktioniert nun auch mit ATAPI CDROMs. AFTER311.NLM muss zuvor manuell geladen werden und Mitsumi Laufwerke werden noch nicht (richtig) unterstuetzt.

Es gibt aber wohl noch Bugs, d.h. mit SCSI-CD-ROM-Laufwerken ist die CDROM3.* immer noch empfehlenswert.

Die Version CDROM3.* ist die erste Version, die nur noch ab Nw 3.12 laeuft und auch nur mit SCSI-CD-ROM-Laufwerken.

Die Version CDROM2.* laeuft bei den meisten (?) noch unter NW 3.11, hat aber Probleme beim Dismounten und erneuten Mounten von CDROMs.

Die Version CDROMFT.* laeuft in dieser Hinsicht besser, kann aber nicht so viele CDROMs erkennen und mounten.

Formel fuer die benoetigte Speicherkapazitaet bei NW 3.xx:

0,023 * Platte (in MB) / Blocksize (in KB) + 2 MB (fuer Netware 3.11)

Bei 4K Blocksize fuer 3 GB: 0,023 * 3,0 * 1024 / 4 + 2 = 19,96

In der Praxis heisst das, das 20 MB knapp sind, 24 MB reichen werden.

Bei 8K Blocksize fuer 3 GB: 0,023 * 3,0 * 1024 / 8 + 2 = 10,83

In der Praxis heisst das, das 16 MB dann genügen...

Dazu muss man aber IMMER noch die zusaetzlich geladenen NLMs hinzurechnen, wie z.B. PServer, ArcServe, Netshield, MPR.

Ausserdem ist der absolute Minimumwert fuer die NW 3.xx 4 MB RAM, bei der NW 4.10 schon 8 MB.

Fehlermeldung: Primary (oder Secondary) interrupt controller detected a lost hardware interrupt

Dahinter verbirgt sich rechnerintern folgendes:

Grob gesagt ensteht diese Meldung immer dann, wenn das anfragende Device seinen Interrupt verliert, bevor der Interrupt-Controller ein O.K. 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. Steht eine Anfrage an, so meldet der PIC über den Master-Interrupt-Eingang der CPU einen Interrupt-Service an. Die CPU wird ihre derzeitige Aufgabe so bald als möglich zwischenspeichern und für diesen Service unterbrechen. Ist die CPU soweit, so erhält der PIC einen Interrupt-Acknowledge,sprich ein O.K., für diesen Interrupt-Service.

Der PIC gibt nun Die Interrupt-Nr. an die CPU weiter. Die CPU liest anhand dieser Nummer in der IRQ-Vector-Tabelle die Einsprungadresse für die zu benutzende Interrupt-Service-Routine (ISR) aus. Diese ISR könnte z.B. ein Device-Treiber sein, der jetzt zu aktivieren ist.

Die ISR signalisiert das Ende einer Interrupt-Bearbeitung mit einem EOI. Der PIC muß also nach dem Acknowledge (INTA) der CPU die Interrupt-Nr. mitteilen. Daher kontrolliert dieser nach dem INTA noch einmal die anstehenden Interrupt-Anfragen. 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

Secundary = Int. 8 - 15

davon abhängig 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. Wie wir soeben gelesen haben, bekommt die CPU nach dem Interrupt-Acknowledge die Interrupt-Nr. zugewiesen. Anhand dieser Int.-Nr. liest sie aus der IRQ-Tabelle die Einsprungadresse der jeweiligen ISR (Treiber). Die IS-Routine kontrolliert das Device und führt die gewünschte Arbeit aus. Findet die ISR aber keine zu verrichtende Arbeit ihres Devices, dann durchsucht die CPU alle IS-Routinen für diese Interrupt-Nr. (da Shared-Interrupt) ab, ob nicht doch irgendjemand was zu verarbeiten hat. Wird auch hier nichts gefunden, erhalten wir die Meldung "Spurious hardware..." und die CPU sendet ein EOI (End Of Interrupt) zum PIC.

Da im rechnerinternen Ablauf durchaus ein Int.-Request verloren geht, ist nicht immer ein Fehler vorhanden. Wir sind uns natürlich darüber einig, daß so etwas nicht vorkommen sollte, aber die Erfahrung lehrt uns hier einiges...

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?

1. Durch eine unsaubere Interrupt-Leitung der eingesetzten FileServer-Hard-

ware (Rechner).

2. 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 mann generell unsaubere Pegelzustände (LOW-HIGH Sprünge). Dies wiederum kann zur Auswirkung haben, daß der PIC den Interrupt nicht mehr lokalisieren kann.

3. Sie besitzen Device-Treiber, die die Interrupt-Anfrage fehlerhaft handhaben oder sogar stören.

4. Die eingesetzte Hardware arbeitet mit den Device-Treibern in Bezug auf diese Interrupt-Anfragen nicht sauber zusammen.

Lösungsmöglichkeiten:

1. 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.

2. 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, dass das Kabel zwischen Multi-IO-Karte und Festplatte zu lang war. Nach einer Verkuerzung war alles ok.

Hilft das alles nichts, testen Sie an einem Rechner verschiedene AT-Bus-Platten, Kabel und Controller.

3. Kontrollieren Sie die Geschwindigkeit des Taktes auf dem Rechnerbus. Eventuell können Sie diesen Bustakt runtersetzen oder auch Waitstates einschalten.

4. Sie bekommen relativ selten diese Meldung und Ihr Netzwerk arbeitet als solches einwandfrei. Dann übersehen Sie zunächst einfach diese Meldung und diese mit "set display lost interrupt alerts = off" und mit "set

display spurious intrrupt alerts = off" am Monitor aus. Beachten Sie jedoch, daß diese Meldungen trotzdem noch in der ERROR-LOG-Datei mitgeschrieben werden.

> Infotext direkt von Adaptec (neue Version!!)

Adaptec Installation

Revision: 06/24/94

(make sure you downloaded latest driver in zip files)

In order to use this procedures you need to test server.exe with your motherboard.

================================================================ Boot to MS-DOS 5.0, 6.0, 6.2 (no config.sys)

run server -ns -na (do not run startup.ncf, autoexec.ncf)
type in fileserver name
type in internal ipx number
type memory

Netware 3.11, 3.12, 4.0x

STARTUP.NCF

set auto register memory above 16 megabytes = on
set reserved buffers below 16 meg = 40
(Add 20 buffers for each additional SCSI device supported by the Adaptec driver with a minimum of 200 buffers for Sbackup, Arcserve)
i.e. load AHA1540 port=xxx
i.e. load AHA1640 port=xxx

Note: - above16=y is not necessary anymore (154x, 1640).
(autodetection of memory)

Procedure II
============ Netware 3.11, 3.12:
-------------------

STARTUP.NCF

set auto register memory above 16 megabytes = off
set reserved buffers below 16 meg = 40
(Add 20 buffers for each additional SCSI device supported by the Adaptec driver with a minimum of 200,300 buffers for Sbackup, Arcserve)

AUTOEXEC.NCF (must be in same path as STARTUP.NCF, C: or A:)

file server name <servername>
ipx internal net <address>
register memory 1000000 ??????? (see Memory)
i.e. load AHA1540 port=xxx
i.e. load AHA1640 port=xxx
(if you have a problem with not mounting the first time, add command line "scan for new devices") mount sys
load <landriver>.lan
bind ...
mount <volumes> (all)
load nlms

STARTUP.NCF

set auto register memory above 16 megabytes = off
set reserved buffers below 16 meg = 40

(Add 20 buffers for each additional SCSI device supported by the Adaptec driver with a minimum of 200 buffers for Sbackup, Arcserve)

register memory 1000000 ??????? (see Memory)
i.e. load AHA1540 port=xxx
i.e. load AHA1640 port=xxx

AUTOEXEC.NCF (can be on SYS: Volume)

file server name <servername>
ipx internal net <address>
load <landriver>.lan
bind ...
mount <volumes> (all)
load nlms

Memory:

-------

register memory <startadress> <range> (both nummbers are in hex: )

decimal 16777216/1048576/65536/4096/256/16/1

16Meg = 1 0 0 0 0 0 0 =1'000'000

Example:

24M :register memory 1'000'000 800'000

32M :register memory 1'000'000 1'000'000

48M :register memory 1'000'000 2'000'000

64M :register memory 1'000'000 3'000'000

Bei der CHIP Treiber CD Nr. 2 ist Personal Netware als Vollversion enthalten mit einer 100 seitigen Dokumentation.

Zu kaufen im gut sortierten Zeitschriftenhandel oder beim Vogel Verlag unter der ISBN 3-8259-1357-0.

Preis 14.80 DM