Kapitel 5. Fehlerbehebung

SCSI-Laufwerke sollten in der Lage sein, diese automatisch zu verlagern. Bei einigen Laufwerken ist diese Eigenschaft jedoch aus unerfindlichen Gründen bei der Auslieferung ausgeschaltet...

Um sie einzuschalten, müssen Sie den Page-Mode des ersten Gerätes editieren. Unter FreeBSD können Sie das (als root) mit folgendem Befehl tun

# camcontrol modepage sd0 -m 1 -e -P 3

und die Werte für AWRE und ARRE von 0 auf 1 ändern:-

AWRE (Auto Write Reallocation Enbld):  1
ARRE (Auto Read Reallocation Enbld):  1
         

Die folgenden Abschnitte wurden von Ted Mittelstaedt <tedm@toybox.placo.com> eingesendet:

Bei IDE-Laufwerken sind fehlerhafte Blöcke normalerweise ein Zeichen für potentielle Probleme. Bei allen modernen IDE-Laufwerken ist eine interne Verlagerung von fehlerhaften Blöcken eingeschaltet. Heutzutage bieten alle IDE-Festplattenhersteller eine umfassende Garantie und tauschen Laufwerke mit fehlerhaften Blöcken um.

Falls Sie ein IDE-Laufwerk mit fehlerhaften Blöcken trotzdem weiterbenutzen möchten, können Sie versuchen, sich vom Hersteller ein IDE-Diagnoseprogramm herunterzuladen und dies über das Laufwerk laufen zu lassen. Manchmal können diese Programme so eingestellt werden, dass sie die Elektronik des Laufwerks dazu veranlassen, das Laufwerk nochmals nach fehlerhaften Blöcken zu durchsuchen und diese auszuschließen.

Auf ESDI-, RLL- und MFM-Laufwerken sind fehlerhafte Blöcke nichts ungewöhnliches und im allgemeinen kein Zeichen für Probleme. Auf einem PC übernehmen der Festplatten-Controller und das BIOS die Aufgabe, fehlerhafte Sektoren auszuschließen, was bei Betriebssystemen wie DOS, die das BIOS benutzen, um auf die Platte zuzugreifen, auch gut funktioniert. Die Festplattentreiber von FreeBSD benutzen allerdings nicht das BIOS, weshalb ein Mechanismus bad144 existiert, der diese Funktionalität ersetzt. bad144 arbeitet nur mit dem wd-Treiber (und wird damit von FreeBSD 4.X nicht unterstützt) und kann NICHT für SCSI benutzt werden. bad144 arbeitet, indem es alle gefundenen, fehlerhaften Sektoren in eine spezielle Datei schreibt.

Eine Einschränkung von bad144 ist, dass die Datei mit den fehlerhaften Sektoren auf die letzte Spur der Platte plaziert wird. Da diese Datei nun möglicherweise eine Liste von fehlerhaften Sektoren enthalten könnte, die am Anfang der Platte auftreten, wo sich möglicherweise die /kernel-Datei befindet, muss sie vom Bootstrap-Programm, das BIOS-Routinen benutzt, um den Kernel zu lesen, erreichbar sein. Das bedeutet, dass Platten, auf denen bad144 benutzt wird, 1024 Zylinder, 16 Köpfe und 63 Sektoren nicht überschreiten dürfen. Platten, die von bad144 verwaltet werden, sind also effektiv auf 500MB begrenzt.

Setzen Sie “Bad Block Scanning” während der Installation im fdisk-Menü einfach auf ON, um bad144 zu verwenden. Dies funktioniert bis zu FreeBSD 2.2.7. Die Platte darf nicht mehr als 1024 Zylinder besitzen. Generell wird empfohlen, dass die Festplatte vorher mindestens vier Stunden in Betrieb war, um ihr die Möglichkeit zur thermischen Ausdehnung und Spurversetzung zu geben.

Falls eine Platte mehr als 1024 Zylinder besitzt (wie z.B. große ESDI-Laufwerke), benutzt der Controller einen speziellen Übersetzungsmodus, um den Betrieb unter DOS zu ermöglichen. Der wd-Treiber kennt diese Übersetzungsmodi, WENN Sie die “translated”-Geometrie mit dem “set geometry”-Befehl in fdisk eingeben. Sie dürfen NICHT den “dangerously dedicated” Modus zur Erstellung der FreeBSD-Partition verwenden, weil dieser die Geometrie ignoriert und obwohl fdisk Ihre überschriebene Geometrie benutzen wird, ist die wahre Größe der Platte noch bekannt und es wird versucht, eine zu große FreeBSD-Partition zu erstellen. Wenn die Plattengeometrie in die übersetzte Geometrie geändert worden ist, dann muss die Partition manuell durch Angabe der Blockanzahl erstellt werden.

Sie können mit dem ESDI-Controller auch kurzerhand eine große ESDI-Platte erstellen, diese dann mit DOS booten und als DOS-Partition formatieren. Anschließend booten Sie mit dem FreeBSD-Installationsprogramm und im fdisk-Menü notieren Sie sich die Blockgröße und die Anzahl Blöcke der DOS-Partition. Dann ändern Sie die Geometrie in die gleiche, wie die von DOS verwendete, löschen die DOS-Partition und erstellen eine “kooperative” FreeBSD-Partition mit der gleichen Blockgröße, die Sie zuvor notiert haben. Machen Sie die Partition nun bootfähig und schalten Sie Bad Block Scanning ein. Während der tatsächlichen Installation wird bad144 gestartet, bevor irgendwelche Dateisysteme erstellt werden (Sie können das mit Alt+F2 beobachten). Falls irgendwelche Probleme bei der Erstellung der Datei mit den fehlerhaften Sektoren auftreten sollten, haben Sie eine zu große Plattengeometrie eingestellt - rebooten Sie Ihr System und beginnen Sie von vorne (die Neupartitionierung und Formatierung unter DOS eingeschlossen).

Falls die Verlagerung fehlerhafter Blöcke aktiviert ist und Sie trotzdem fehlerhafte Blöcke bemerken, sollten Sie einen Austausch des Laufwerkes in Erwägung ziehen, da die fehlerhaften Blöcke mit der Zeit zunehmen werden.

Diese Information ist speziell für die 742a, könnte aber auch andere Buslogic-Karten einschließen (Bustek = Buslogic)

Es gibt zwei grundverschiedene “Versionen” der 742a-Karte. Das sind die Hardware-Revisionen A-G und Revisionen von H aufwärts. Der Revisionsbuchstabe befindet sich hinter der Fabriknummer am Rand der Karte. Auf der 742a befinden sich zwei Chips. Einer ist der BIOS-Chip, der andere der Firmware-Chip. FreeBSD achtet nicht darauf, welche BIOS-Version Sie haben, aber es achtet auf die Version des Firmware-Chips. Buslogic schickt Ihnen Upgrade-ROMs, wenn Sie sich an den technischen Support wenden. Die BIOS- und Firmware-Chips müssen als passende Paare ausgeliefert werden. Für Ihre Hardware-Revision benötigen Sie das aktuellste Firmware-ROM auf Ihrer Adapter-Karte.

Karten der Revision A-G akzeptieren BIOS/Firmware-Paare bis zu 2.41/2.21. Die Karten der Revisionen H und aufwärts akzeptieren die aktuellsten BIOS/Firmware-Paare 4.70/3.37. Der Unterschied der Firmware-Versionen ist, dass die 3.37-Firmware “round robin” unterstützt.

Auf den Buslogic-Karten befindet sich auch eine Seriennummer. Falls Sie eine Karte mit einer alten Hardwarerevisionsnummer besitzen, können Sie sich an die RMA-Abteilung von Buslogic wenden, Ihre Seriennummer angeben und versuchen, die Karte gegen eine neuere Hardwarerevision auszutauschen. Falls Ihre Karte nicht zu alt ist, wird dem Tausch zugestimmt werden.

Von FreeBSD 2.1 werden nur Firmwarerevisionen ab 2.21 aufwärts unterstützt. Wenn Sie eine ältere Firmwarerevision besitzen, wird Ihre Karte nicht als Buslogic-Karte erkannt. Sie könnte jedoch als Adaptec® 1540 erkannt werden. Die frühe Firmware von Buslogic enthält eine AHA1540 “Emulation”, wovon bei EISA-Karten jedoch abzuraten ist.

Wenn sie eine Karte mit einer alten Hardwarerevisionsnummer besitzen und die 2.21-Firmware für sie bekommen, müssen Sie den Jumper W1 in die Position B-C setzen; die Voreinstellung ist A-B.

Hierbei handelt es sich um ein bekanntes Problem. Der auf dem Board befindliche EISA-SCSI-Controller auf dem HP Netserver belegt die EISA-Slotnummer 11, wodurch sich alle “wirklichen” EISA-Slots vor ihm befinden. Leider kollidiert der Adressraum von EISA-Slots >=10 mit dem Adressraum, der PCI zugeordnet ist und die Autokonfiguration von FreeBSD kann mit dieser Situation derzeit nicht besonders gut umgehen.

Die einfachste Alternative ist, diese Kollision einfach zu leugnen. Setzen Sie dazu die Kerneloption EISA_SLOTS auf den Wert 12. Konfigurieren und kompilieren Sie den Kernel, wie im Handbucheintrag zur Kernelkonfiguration beschrieben.

Dies bringt Ihnen natürlich das klassische Huhn-Ei-Problem, wenn Sie auf einer solchen Maschine installieren wollen. Um dieses Problem zu umgehen, existiert ein spezieller Hack in UserConfig. Benutzen Sie nicht die “visuelle” Schnittstelle, sondern die rohe Kommandozeilenschnittstelle. Geben Sie einfach

eisa 12
quit
         

am Prompt ein und Sie können Ihr System ganz normal installieren. Sie sollten auf jeden Fall einen angepassten Kernel zu kompilieren und installieren.

Zukünftige Versionen werden hoffentlich eine passende Lösung für dieses Problem beinhalten.

Dies wird meistens durch einen Interruptkonflikt verursacht (z.B., wenn zwei Karten den selben Interrupt benutzen). Vor 2.0.5R war FreeBSD diesbezüglich tolerant und die Treiber für Netzwerkkarten funktionierten auch bei IRQ-Konflikten. Seit 2.0.5R werden IRQ-Konflikte jedoch nicht länger toleriert. Booten Sie mit der Option -c und ändern Sie die Einträge zu ed0/de0/... Ihrem Board entsprechend.

Wenn Sie den BNC-Anschluss Ihrer Netzwerkkarte benutzen, könnte es auch sein, dass es sich Geräte-Timeouts aufgrund fehlerhafter Terminierung handelt. Um dies zu überprüfen, verbinden Sie einen Terminator direkt mit der Netzwerkkarte (ohne Kabel) und beobachten Sie, ob die Fehlermeldungen verschwinden.

Einige NE2000 kompatible Karten melden diesen Fehler, wenn keine Verbindung am UTP-Eingang existiert oder wenn das Kabel nicht eingesteckt ist.

Diese Karte ist dafür berüchtigt, ihre Konfiguration zu vergessen. Sie müssen die Karte mit dem DOS-Programm 3c5x9.exe neu konfigurieren.

Falls das einzige Problem ist, dass er schrecklich langsam ist, dann sollte Sie versuchen, die Kommunikationseinstellungen der parallelen Schnittstellen zu ändern, wie es im Kapitel Drucken des Handbuchs beschrieben ist.

Das Signal 11 wird generiert, wenn ein Prozess versucht, auf Speicher zuzugreifen, obwohl er vom Betriebssystem dazu nicht befugt wurde. Wenn Ihnen das scheinbar zufällig immer wieder passiert, sollten Sie der Sache einmal auf der Grund gehen.

Das Problem hat in der Regel eine der folgenden Ursachen:

1. Wenn das Problem nur in einer bestimmten Anwendung auftritt, die Sie selbst entwickeln, dann ist es wahrscheinlich ein Fehler in Ihren Sourcen.

2. Wenn das Problem in einem Teil von FreeBSD auftritt, könnte es natürlich auch ein Fehler sein; aber in den meisten Fällen werden diese Probleme gefunden und behoben, bevor die typischen Leser der FAQ (wir) diese Teile der Sourcen benutzen können (dafür gibt es schließlich -CURRENT).

Wenn der Fehler auftritt, wenn Sie ein Programm compilieren aber dabei immer wieder an anderer Stelle auftritt, dann ist das ein ganz eindeutiger Hinweis, dass das Problem nicht bei FreeBSD liegt.

Nehmen wir zum Beispiel an, dass Sie “make buildworld” ausführen und die Compilierung von ls.c in ls.o abbricht. Wenn Sie nochmal "make buildworld" durchführen und die Compilierung an der gleichen Stelle abbricht, handelt es sich um einen Fehler in den Sourcen. Aktualisieren Sie Ihre Sourcen und versuchen Sie es noch einmal. Wenn der Fehler jedoch an einer anderen Stelle auftritt, liegt das Problem mit an Sicherheit grenzender Wahrscheinlichkeit bei Ihrer Hardware.

Was Sie tun sollten:

Im ersten Fall können Sie einen Debugger wie z.B. gdb benutzen, um die Stelle im Programm zu finden, an der auf eine falsche Adresse zugegriffen wird und danach den Fehler beheben.

Im zweiten Fall müssen Sie sicherstellen, dass das Problem nicht von Ihrer Hardware verursacht wird.

Typische Ursachen dafür sind unter anderem:

1. Es könnte sein, dass Ihren Festplatten zu warm werden: Überprüfen Sie, ob die Lüfter in Ihrem Gehäuse noch funktionieren, damit Ihre Festplatten (und andere Hardware) nicht heißlaufen.

2. Der Prozessor überhitzt, weil Sie Ihn übertaktet haben oder der CPU-Kühler ausgefallen ist. Sie müssen sicherstellen, dass Sie Ihre Hardware unter den Bedingungen betreiben, für die sie spezifiziert ist, zumindestens während Sie versuchen, das Problem zu lösen. Mit anderen Worten: Betreiben Sie Ihre CPU mit der normalen Taktfrequenz.

   Wenn Sie übertakten, sollten Sie daran denken, dass ein langsames System deutlich billiger ist als ein defektes System. Die große Masse hat nicht sehr häufig Mitgefühl mit Problemen bei übertakteten System, auch wenn Sie es für ungefährlich halten.

3. Unzuverlässiger Speicher: Wenn Sie mehr als ein SIMM/DIMM installiert haben, sollten Sie sie alle ausbauen und die Maschine testweise mit jedem SIMM oder DIMM einzeln betreiben. So können Sie feststellen, ob die Ursache ein einzelnes SIMM/DIMM oder auch eine Kombination von Modulen ist.

4. Zu optimistische Einstellung des Mainboards: In Ihrem BIOS und mit den Jumpern auf dem Mainboard können Sie diverse Timings ändern. In den meisten Fällen reichen die Defaults aus, aber manchmal kann es durch zu wenig wait states, die Einstellung “RAM Speed: Turbo” oder ähnliches zu merkwürdigen Problemen kommen. Ein möglicher Ansatz ist, die BIOS defaults zu laden, allerdings könnte es sinnvoll sein, die aktuellen Einstellungen vorher zu notieren.

5. Schlechte oder fehlerhafte Stromversorgung des Mainboards: Wenn Sie unbenutzte Steckkarten, Platten oder CDROMs in Ihrem System haben, sollten Sie sie testweise ausbauen oder die Stromversorgung abziehen. Dadurch können Sie prüfen, ob Ihr Netzteil eventuell mit einer geringeren Last besser zurechtkommt. Sie können auch testweise ein anderes, am besten ein leistungsfähigeres, Netzteil ausprobieren. Wenn Sie zurzeit ein 250W-Netzteil benutzen, sollten Sie testweise ein 300W-Netzteil einbauen.

Die sollten ebenfalls die SIG11 FAQ (unten aufgeführt) lesen, da sie gute Erklärungen für alle diese Probleme enthält (allerdings aus Linux®-Sicht). Sie erklärt ebenfalls, warum sowohl Programme als auch Geräte zur Speicherprüfung fehlerhaften Speicher teilweise nicht erkennen.

Wenn alle diese Schritte nicht helfen, ist es möglich, dass Sie einen Fehler in FreeBSD gefunden haben. Folgen Sie einfach den Anweisungen für die Erstellung eines Problem Reports.

Es existiert eine ausführliche FAQ hierzu unter der SIG11-Problem-FAQ

Die Entwickler von FreeBSD interessieren sich für solchen Meldungen, allerdings brauchen Sie deutlich mehr Informationen als die, die Ihnen angezeigt werden. Kopieren Sie die komplette Meldungen und lesen Sie nun den FAQ-Eintrag über kernel panics. Erzeugen sie einen Kernel mit den zusätzlichen Daten zur Fehlersuche, und dann einen backtrace. Das hört sich komplizierter an, als es ist. Sie brauchen keine Programmier-Erfahrung, Sie müssen einfach nur den Anweisungen folgen.

Dies ist ein bekanntes Problem mit der ATI Mach 64 Videokarte. Das Problem besteht darin, dass diese Karte die Adresse 2e8 benutzt und die vierte serielle Schnittstelle ebenfalls. Aufgrund eines Fehlers (einer Besonderheit?) im sio(4)-Treiber wird diese Schnittstelle angesprochen, auch wenn Sie gar keine vierte serielle Schnittstelle besitzen und sogar, wenn sie sio3 (die vierte Schnittstelle), die normalerweise diese Adresse verwendet, deaktivieren.

Bis der Fehler behoben ist, können Sie folgende Abhilfe verwenden:

1. Geben Sie am Bootprompt -c ein. (Dies bringt den Kernel in den Konfigurationsmodus).

2. Deaktivieren Sie sio0, sio1, sio2 und sio3 (alle). Auf diese Weise wird der sio-Treiber nicht aktiviert und das Problem tritt nicht mehr auf.

3. Geben Sie exit ein, um den Bootvorgang fortzusetzen.

Falls sie in der Lage sein wollen Ihre seriellen Schnittstellen zu benutzen, müssen Sie einen neuen Kernel mit folgenden Modifikationen erstellen: suchen Sie in /usr/src/sys/i386/isa/sio.c nach der Zeichenkette 0x2e8 und löschen Sie sie und das vorhergehende Komma (nicht das folgende Komma). Nun folgen Sie der normalen Prozedur zur Erstellung eines neuen Kernels.

Auch nach Anwendung dieser Maßnahmen könnte es sein, dass Ihr X Windows-System nicht einwandfrei funktioniert. Wenn dies der Fall ist, stellen Sie sicher, dass es sich bei der von Ihnen benutzten X Windows-Version mindestens um XFree86™ 3.3.3 oder höher handelt. Diese Version und höhere besitzen eine integrierte Unterstützung für Mach64-Karten und sogar einen dedizierten X-Server für sie.

Aufgrund der Art und Weise, wie FreeBSD die Hauptspeichergröße vom BIOS mitgeteilt bekommt, kann es lediglich 16-Bit Werte in kByte-Größe (65535 kByte = 64MB) erkennen (oder weniger... einige BIOSe setzen die Hauptspeichergröße auf 16MB). Falls Sie mehr als 64MB besitzen, wird FreeBSD versuchen, das zu erkennen, was aber nicht immer funktioniert.

Um dieses Problem zu umgehen, müssen Sie die untenstehende Kerneloption verwenden. Es gibt einen Weg, vollständige Hauptspeicherinformationen vom BIOS zu erhalten, aber in den Bootblöcken ist nicht genügend Platz dafür vorhanden. Wenn der Platzmangel in den Bootblöcken eins Tages behoben ist, werden wir die erweiterten BIOS-Funktionen dazu nutzen, die vollständigen Hauptspeicherinformationen zu erhalten... aber zurzeit sind wir auf die Kerneloption angewiesen.

options "MAXMEM=n"

Hierbei ist n Ihre Hauptspeichergröße in Kilobyte. Bei einer 128 MB-Maschine müßten Sie 131072 benutzen.

Im Normalfall bestimmt FreeBSD einige Kernelparameter, darunter die maximale Anzahl der Dateien, die gleichzeitig geöffnet sein können, aus der Größe des im System installierten Hauptspeichers. Auf Systemen mit mindestens 1 GB Hauptspeicher kann dieser “auto sizing”-Mechanismus diese Werte fälschlicherweise zu hoch ansetzen: Beim Systemstart fordert der Kernel dann verschiedene Tabellen und andere Strukturen an, die den Großteil des verfügbaren Kernelspeichers verbrauchen. Dies führt dazu, dass der Kernel während des Betriebs keine dynamischen Speicheranforderungen mehr ausführen kann und mit einer Kernelpanik abstürzt.

Bauen Sie in diesem Fall Ihren eigenen Kernel. Dazu setzen Sie VM_KMEM_SIZE_MAX in Ihrer Kernelkonfigurationsdatei auf 400 MB (options VM_KMEM_SIZE_MAX=419430400). 400 MB sollten für Maschinen bis 6 GB Hauptspeicher ausreichend sein.

Diese Meldung zeigt an, dass der virtuelle Speicher für Netzwerkpuffer (spezieller mbuf-Cluster) aufgebraucht ist. Sie können die für mbuf verfügbare Größe an VM erhöhen, indem Sie

options NMBCLUSTERS=n

in Ihre Kernelkonfigurationsdatei einfügen, wobei n, abhängig davon, wie viele gleichzeitige TCP-Verbindungen Sie unterstützen müssen, eine Zahl aus dem Bereich 512-4096 ist. Wir würden Ihnen empfehlen, 2048 zu probieren - das sollte Sie von solchen Paniksituationen vollkommen befreien. Sie können die Anzahl der zugeordneten/benutzten mbuf-Cluster im System mit netstat -m beobachten. Der voreingestellte Wert für NMBCLUSTERS ist 1024 + MAXUSERS * 64.

Der FreeBSD-Kernel beschränkt die Anzahl der gleichzeitig laufenden Prozesse. Die Anzahl errechnet sich aus dem Wert der Variablen MAXUSERS in der Konfigurationsdatei des Kernels. Auch andere Einstellungen wie die Anzahl der Puffer für Netzwerkoperationen (Details dazu finden Sie in diesem Abschnitt). werden durch MAXUSERS beeinflusst. Wenn Ihr System stark belastet ist, sollten Sie den Wert von MAXUSERS erhöhen. Dadurch werden diverse Einstellung des Systems angepasst und die maximale Anzahl gleichzeitig laufender Prozesse erhöht.

Seit FreeBSD 4.4 kann der Wert von MAXUSERS über die Variable kern.maxusers in der Datei /boot/loader.conf angepasst werden. In älteren Versionen mussten Sie MAXUSERS in der Konfigurationsdatei für Ihren angepassten Kernel ändern.

Wenn Ihr System nicht besonders stark ausgelastet ist und Sie einfach nur mehr gleichzeitig laufende Prozesse erlauben wollen, können Sie den Wert des sysctl kern.maxproc erhöhen. Wenn diese Prozesse von einem einzigen Benutzer ausgeführt werden, müssen Sie den Wert von kern.maxprocperuid ebenfalls erhöhen. Dieser Wert muss immer mindestens um eins geringer sein als der Wert von kern.maxproc value. (Der Grund für diese Einschränkung ist, dass ein Systemprogramm, init(8), immer ausgeführt werden muss.)

Damit Änderungen eines sysctl auch bei einem Neustart des Systems erhalten bleiben, müssen Sie diese bei aktuellen FreeBSD-Versionen in /etc/sysctl.conf eintragen. In älteren Versionen wurden sie in /etc/rc.local eingetragen.

Die Logik, die versucht, veraltete /var/db/kvm_*.db-Dateien zu erkennen, versagt manchmal und die Benutzung einer unpassenden Datei kann zu Paniksituationen führen.

Falls das passiert, rebooten Sie im Single-User-Modus und löschen Sie die Dateien:

# rm /var/db/kvm_*.db

Dies ist ein Konflikt mit einem Ultrastor SCSI Hostadapter.

Rufen Sie während des Bootprozesses das Kernelkonfigurationsmenü auf und deaktivieren Sie uha0, welches das Problem verursacht.

Auf Ihrem Mainboard fehlen ein paar Logikbausteinen, die für die Unterstützung der automatischen Terminierung notwendig sind. Stellen Sie in Ihrem SCSI-BIOS manuell die korrekte Terminierung für Ihr System ein, anstatt sich auf die automatische Terminierung zu verlassen. Der Treiber für den AIC7XXX kann nicht erkennen, ob die externen Logikbausteine für die Erkennung der Kabel (und damit automatische Terminierung) vorhanden sind. Der Treiber muss sich darauf verlassen, dass diese vorhanden sind, wenn in der Konfiguration “automatische Terminierung” eingestellt ist. Ohne die externen Bausteine ist es sehr wahrscheinlich, dass der Treiber die Terminierung falsch einstellt, was die Zuverlässigkeit des SCSI-Busses herabsetzen kann.

Dies wird in der Sendmail-FAQ wie folgt beantwortet:-

        * Ich erhalte "Local configuration error" Meldungen, wie:

        553 relay.domain.net config error: mail loops back to myself
        554 <user@domain.net>... Local configuration error

        Wie kann ich dieses Problem lösen?

        Sie haben durch die Benutzung einer MX-Zeile eingestellt, dass
        Mail für die Domäne (z.B. domain.net) an einen speziellen
        Host (in diesem Fall relay.domain.net) weitergeleitet wird,
        aber der Relay-Host erkennt sich selbst nicht als
        domain.net.  Fügen Sie domain.net in /etc/mail/local-host-names
        (falls Sie FEATURE(use_cw_file) benutzen) oder "Cw domain.net"
        in /etc/mail/sendmail.cf ein.
            

Die aktuelle Version der Sendmail-FAQ wird nicht mehr mit dem Sendmail-Release verwaltet. Sie wird jedoch regelmäßig nach comp.mail.sendmail, comp.mail.misc, comp.mail.smail, comp.answers und news.answers gepostet. Sie können auch eine Kopie per E-Mail bekommen, indem Sie eine Mail mit dem Inhalt send usenet/news.answers/mail/sendmail-faq an <mail-server@rtfm.mit.edu> schicken.

Die entfernte Maschine scheint den Terminaltyp auf etwas anderes als den Typ cons25, der von FreeBSD verlangt wird, zu setzen.

Es gibt mehrere mögliche Abhilfen für dieses Problem:

• Setzen Sie die Shell-Variable TERM nach dem Einloggen auf der entfernten Maschine auf ansi oder sco, sofern die entfernte Maschine diese Terminaltypen kennt.

• Benutzen Sie einen VT100-Emulator wie screen auf der FreeBSD-Console. screen bietet Ihnen die Möglichkeit, mehrere gleichzeitige Sitzungen von einem Bildschirm aus laufen zu lassen. Es ist ein sehr nettes Programm. Jedes screen-Fenster verhält sich, wie ein VT100-Terminal, weshalb die Variable TERM am entfernten Ende auf vt100 gesetzt werden sollte.

• Installieren Sie den Eintrag cons25 in der Bildschirmdatenbank der entfernten Maschine. Wie das zu geschehen hat, hängt vom Betriebssystem der entfernten Maschine ab. Das Systemadministrationshandbuch für das entfernte System sollte Ihnen hierbei helfen können.

• Starten Sie einen X-Server auf der FreeBSD-Seite und benutzen Sie einen X-basierten Terminalemulator wie xterm oder rxvt, um sich auf der entfernten Maschine einzuloggen. Die Variable TERM auf dem entfernten Host sollte auf xterm oder vt100 gesetzt werden.

Dies kann durch verschiedene Hardware- oder Softwareprobleme in Verbindung mit Interrupts verursacht werden. Das kann aufgrund von Fehlern sein, aber es kann auch durch die Eigenarten bestimmter Geräte passieren. TCP/IP über die parallele Schnittstelle mit einer großen MTU laufen zu lassen, ist ein sicherer Weg, um dieses Problem hervorzurufen. Grafikbeschleuniger können es auch verursachen. In diesem Fall sollten Sie zunächst die Interrupteinstellungen der Karte überprüfen.

Ein Seiteneffekt dieses Problems sind Prozesse, die mit der Meldung “SIGXCPU exceeded cpu time limit” abbrechen.

Für FreeBSD 3.0 und spätere ab dem 29. Nov. 1998: Falls das Problem nicht anders gelöst werden kann, besteht die Lösung darin, diese sysctl-Variable zu setzen:

# sysctl -w kern.timecounter.method=1

Das bedeutet zwar Performanceeinbußen, aber in Anbetracht der Ursache für dieses Problem werden Sie das wahrscheinlich nicht bemerken. Fall das Problem weiter bestehen bleibt, lassen sie die sysctl-Variable auf 1 stehen und setzen Sie die Option NTIMECOUNTER im Kernel auf immer höhere Werte. Wenn Sie irgendwann NTIMECOUNTER=20 erreicht haben sollten, ist das Problem nicht gelöst. Die Interrupts auf Ihrer Maschine sind für eine verlässliche Zeiterhaltung nicht zu gebrauchen.

Dieser Effekt tritt auf, wenn Sie FreeBSD 3.X und eine PCI Soundkarte haben. Das Gerät pcm0 ist für ISA Soundkarten reserviert; wenn Sie eine PCI Soundkarte haben, werden Sie diese Meldung erhalten und Ihre Karte wird als pcm1 eingebunden.

Wenn Sie eine PCI Sounkarte haben, müssen Sie das Gerät snd1 statt des üblichen snd0 verwenden:

# cd /dev
# ./MAKEDEV snd1

Dieses Problem tritt in FreeBSD 4.X nicht mehr auf, da große Anstrengungen unternommen wurden, diese Version PnP-orientiert zu machen. In FreeBSD 4.X ist das Gerät pcm0 nicht mehr für ISA-Karten reserviert.

FreeBSD 4.X ist deutlich PnP-orientierter und das führt leider dazu, dass einige PnP-Geräte (wie z.B. Soundkarten und interne Modems) nicht mehr funktionieren, obwohl Sie von FreeBSD 3.X noch erkannt wurden.

Die Gründe für dieses Verhalten werden in der unten zitierten Mail von Mail von Peter Wemm erklärt. Diese Mail stammt von der Mailingliste freebsd-questions und war eine Antwort auf eine Frage bezüglich eines internen Modem, das nach dem Update auf FreeBSD 4.X nicht mehr erkannt wurde.

Das PnP-BIOS hat es [das Modem] vorkonfiguriert und es dann im Adressraum liegenlassen, daher haben es die alten ISA-Erkennungsroutinen [in 3.X] “gefunden”.

In 4.0 sind die ISA-Routinen deutlich PnP-orientierter. Es war möglich [in 3.X], dass eine ISA-Erkennungsroutinen ein “zugelaufenes” Gerät fand; während die PnP-Treiber zwar die ID erkannten, das Gerät aber wegen des Ressourcekonfliktes nicht benutzen konnten. Daher werden die programmierbaren Karten zunächst einmal abgeschaltet, um diese doppelte Erkennung vermeiden zu können. Das bedeutet allerdings auch, dass die Treiber die PnP-ID kennen muss, um PnP-Hardware unterstützen zu können. Wir haben uns vorgenommen, den Benutzern eine einfachere Möglichkeit zur Manipulation dieser Informationen zur Verfügung zu stellen.

Damit Ihr Gerät wieder funktioniert, müssen Sie seine PnP-ID herausfinden und die ID in die Listen eintragen, die zur Erkennung von PnP-Geräten genutzten werden. Zu diesem Zweck wird das Gerät mit pnpinfo(8) analysiert. Das Beispiel zeigt die Ausgaben von pnpinfo(8) für ein internes Modem:

# pnpinfo
Checking for Plug-n-Play devices...

Card assigned CSN #1
Vendor ID PMC2430 (0x3024a341), Serial Number 0xffffffff
PnP Version 1.0, Vendor Version 0
Device Description: Pace 56 Voice Internal Plug & Play Modem

Logical Device ID: PMC2430 0x3024a341 #0
        Device supports I/O Range Check
TAG Start DF
    I/O Range 0x3f8 .. 0x3f8, alignment 0x8, len 0x8
        [16-bit addr]
    IRQ: 4  - only one type (true/edge)

[weitere TAG Zeilen gestrichen]

TAG End DF
End Tag

Successfully got 31 resources, 1 logical fdevs
-- card select # 0x0001

CSN PMC2430 (0x3024a341), Serial Number 0xffffffff

Logical device #0
IO:  0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8
IRQ 5 0
DMA 4 0
IO range check 0x00 activate 0x01

Sie benötigen die Information aus der Zeile “Vendor ID” ganz im Anfang. Die in Klammern ausgegebene hexadezimale Zahl (0x3024a341 in diesem Beispiel) ist die PnP ID und die unmittelbar davor stehende Zeichenkette (PMC2430) ist eine eindeutige Herstellerkennung.

Benutzen Sie pciconf(8) wenn pnpinfo(8) die Karte nicht anzeigt. Der Teil der Ausgabe von pciconf -vl für eine auf dem Motherboard integrierte Soundkarte sieht zum Beispiel so aus:

# pciconf -vl
chip1@pci0:31:5:        class=0x040100 card=0x00931028 chip=0x24158086 rev=0x02 hdr=0x00
    vendor   = 'Intel Corporation'
    device   = '82801AA 8xx Chipset AC'97 Audio Controller'
    class    = multimedia
    subclass = audio

Sie benötigen die Chip-ID “0x24158086”, die hinter chip aufgeführt ist.

Die Herstellerkennung oder die Chip-ID müssen in die Datei /usr/src/sys/isa/sio.c eingetragen werden.

Sie sollten zunächst ein Backup von sio.c anlegen, falls etwas schief gehen sollte. Sie werden auch einen Patch erzeugen müssen, um ihn zusammen mit Ihrem PR einzusenden. (Sie wollten doch einen PR schreiben, oder etwa nicht?) Öffnen Sie nun sio.c mit einem Editor und suchen Sie nach der Zeile

static struct isa_pnp_id sio_ids[] = {

und blättern Sie dann nach unten, um die passende Stelle für Ihr Gerät zu finden. Unten finden Sie Beispiel für die Einträge, diese sind nach der Herstellerkennung sortiert. Diese sollte in dem Kommentar auf der rechten Seite aufgenommen werden, dazu kommt die Gerätebeschreibung (Device Description) aus der Ausgabe von pnpinfo(8):

{0x0f804f3f, NULL},     /* OZO800f - Zoom 2812 (56k Modem) */
{0x39804f3f, NULL},     /* OZO8039 - Zoom 56k flex */
{0x3024a341, NULL},     /* PMC2430 - Pace 56 Voice Internal Modem */
{0x1000eb49, NULL},     /* ROK0010 - Rockwell ? */
{0x5002734a, NULL},     /* RSS0250 - 5614Jx3(G) Internal Modem */
        

Fügen Sie die hexadezimale Gerätekennung an der richtigen Stelle ein, speichern Sie die Datei ab, erzeugen Sie einen neuen Kernel und starten Sie Ihr System neu. Ihr Gerät sollte nun wie bei FreeBSD 3.X als sio Gerät erkannt werden.

Das Programm sucht nach einem speziellen Symbol im Kernel, kann es aber aus irgendeinem Grunde nicht finden. Dieser Fehler wird von einem dieser Probleme verursacht:

• Ihr Kernel und die sonstigen Programme (das “Userland”) sind nicht mehr auf dem gleichen Stand. Mit anderen Worten, Sie haben zwar einen neuen Kernel erzeugt, aber kein installworld (oder umgekehrt); darum weicht die Symboltabelle von dem ab, was die Anwendung erwartet. Wenn dies der Fall ist, müssen Sie lediglich die noch fehlenden Schritte des Upgrades durchführen. Die richtige Vorgehensweise kann /usr/src/UPDATING entnommen werden.

• Um Ihren Kernel zu laden, benutzen Sie nicht /boot/loader, sondern laden ihn direkt mit boot2 (siehe boot(8)). Es ist zwar nicht immer ein Fehler, /boot/loader zu umgehen; allerdings ist er in der Regel besser dazu geeignet, die Symbole des Kernels für normale Anwendungen verfügbar zu machen.

Das Symptom: Nach dem Aufbau des TCP-Verbindung vergeht einige Zeit, bis endlich die Abfrage des Passwortes (bzw. der Login-Prompt bei Telnet) erscheint.

Das Problem: In den meisten Fällen versucht der Server in der Zwischenzeit, die IP-Adresse des Clients in einen Rechnernamen zu übersetzen. Viele Server (darunter die Telnet und SSH Server von FreeBSD) machen das, um den Hostnamen z.B. für spätere Verwendung durch den Systemadministrator in eine Protokolldatei schreiben zu können.

Die Lösung: wenn das Problem bei jedem Server auftritt, den Sie von Ihrem Computer (dem Client) ansprechen, dann wird das Problem vom Client verursacht. Wenn das Problem aber nur auftritt, wenn jemand Ihren Rechner (den Server) anspricht, dann liegt die Ursache beim Server.

Wenn das Problem vom Client verursacht wird, müsssen Sie die Einträge im DNS korrigieren, damit der Server Ihre IP-Adresse übersetzen kann. Wenn das Problem in Ihrem lokalen Netzwerk auftritt, sollten Sie es als Problem des Servers behandeln und weiterlesen; wenn es allerdings im Internet auftritt, werden Sie sich wahrscheinlich an Ihrem ISP wenden müssen, damit dieser das Problem für Sie korrigiert.

Wenn das Problem vom Server verursacht wird und Sie sich in einem lokalen Netzwerk befinden, dann müssen Sie Ihren Server so konfigurieren, dass er die lokal genutzten IP-Adressen in Rechnernamen übersetzen kann. Weitere Informationen erhalten Sie in den Onlinehilfen zu hosts(5) und named(8). Wenn dieses Problem im Internet auftritt, könnte die Ursache auch darin liegen, dass die Namensauflösung auf dem Server nicht funktioniert. Versuchen Sie, einen anderen Hostnamen wie z.B. www.yahoo.com aufzulösen. Wenn das nicht funktioniert, liegt das Problem bei Ihrem System.

Stray IRQs sind ein Zeichen für Probleme bei der Behandlung von Hardware-IRQs. Sie werden meistens von Geräten verursacht, die ihren Interrupt Request zurückziehen, obwohl gerade der interrupt request acknowledge-Zyklus läuft.

Sie können drei Dinge tun:

• Ertragen Sie die Warnungen. Sie erhalten nur die ersten 5 für jeden IRQ, alle anderen werden unterdrückt.

• Eliminieren Sie die Meldungen, indem Sie in isa_strayintr() den Wert 5 auf 0 ändern, um alle Meldungen zu unterdrücken.

• Eliminieren Sie die Meldungen, indem Sie Hardware für den Parallelport installieren, die IRQ 7 nutzt und vom PPP Treiber verwendet wird (das passiert auf den meisten Systemen), und installieren Sie eine IDE-Platte oder andere Hardware sowie einen dazu passenden Treiber, um IRQ 15 zu nutzen.

Diese Fehlermeldung besagt, dass Sie die zur Verfügung stehenden File-Handles des Systems verbraucht haben. Was das genau bedeutet und wie Sie dieses Problem lösen können, steht im Abschnitt kern.maxfiles im Kapitel Anpassung der Kernelkonfiguration des Handbuchs.

Ihr Laptop verfügt über mehr als eine Uhr und FreeBSD benutzt leider die falsche.

Starten Sie dmesg(8) und achten Sie auf die Zeilen, in denen das Wort Timecounter vorkommt. Die von FreeBSD benutzte Uhr steht in der letzten Zeile, mit an Sicherheit grenzender Wahrscheinlichkeit wird es TSC sein.

# dmesg | grep Timecounter
 Timecounter "i8254"  frequency 1193182 Hz
 Timecounter "TSC"  frequency 595573479 Hz

Sie können das überprüfen, indem Sie den Wert der Systemvariablen kern.timecounter.hardware abfragen.

# sysctl kern.timecounter.hardware
 kern.timecounter.hardware: TSC

Es ist durchaus möglich, dass das BIOS die TSC Uhr ändert, um beispielsweise den CPU-Takt zu während des Batteriebetrieb zu ändern, oder im Stromsparmodus; leider bemerkt FreeBSD diese Änderungen nicht und daher scheint die Uhr falsch zu gehen.

In diesem Beispiel ist die Uhr i8254 ebenfalls verfügbar; um sie auszuwählen, muss ihr Name in die Systemvariable kern.timecounter.hardware geschrieben werden.

# sysctl -w kern.timecounter.hardware=i8254
 kern.timecounter.hardware: TSC -> i8254

Die Uhrzeit Ihres Laptops sollte nun genauer funktionieren.

Damit diese Änderung automatisch beim Start des Systems durchgeführt wird, müssen Sie die folgende Zeile in die /etc/sysctl.conf eintragen.

kern.timecounter.hardware=i8254

Dieses Problem tritt häufig auf Laptops mit mehreren Betriebssystemen auf. Einige nicht-BSD Betriebssysteme lassen die Hardware in einem inkonsistenten Zustand. Die Karte wird dann von pccardd als “"(null)""(null)"” anstelle des tatsächlichen Modells gefunden.

Um dies zu beheben, müssen Sie die Hardware zurücksetzen, das heißt der PC-Card Einschub muss stromlos sein. Gehen Sie dazu nicht in den Standby- oder Suspend-Modus und stellen Sie sicher, dass der Laptop wirklich ausgeschaltet ist. Warten Sie einen Moment und booten dann, Ihre PC-Card sollte jetzt funktionieren.

Einige Laptops schalten sich nicht wirklich aus. Wenn der obige Vorschlag nichts genutzt hat, entfernen Sie bitte die Batterie, warten einen Moment und booten erneut.

Der Bootloader von FreeBSD erkennt die Geometrie Ihrer Festplatte nicht richtig. Sie müssen die Geometrie manuell festlegen, wenn sie mit fdisk FreeBSD-Bereiche erzeugen oder ändern.

Die richtigen Werte für die Geometrie können Sie im BIOS des Rechners ablesen. Achten Sie auf die Anzahl der Zylinder, Köpfe und Sektoren für Ihre Festplatte.

Im fdisk von sysinstall(8) müssen Sie G eingeben, um die Geometrie zu definieren.

Sie erhalten eine Dialogbox, in der Sie die Anzahl der Zylinder, Köpfe und Sektoren eingeben können. Verwenden Sie die Angaben des BIOS und setzen Sie Schrägstriche zwischen die Zahlen. 5000 Zylinder, 250 Köpfe und 60 Sektoren würden also als 5000/250/60 eingegeben.

Schließen Sie die Eingabe mit Enter ab und drücken Sie W, um die neue Partitionstabelle auf die Festplatte schreiben zu lassen.

Starten Sie sysinstall(8) und wählen Sie Configure, dann Fdisk. Wählen Sie die Platte, auf der sich der Boot Manager befand, mit der Leertaste aus. Drücken Sie W, um die Änderungen auf die Platten schreiben zu lassen. Nun erscheint eine Abfrage, welcher Bootmanager installiert werden soll. Wählen Sie diesen an und er wird wieder installiert.

Ein Programm wollte Speicher auf Platte auslagern, und dieser Vorgang konnte nicht innerhalb von 20 Sekunden durchgeführt werden. Mögliche Gründe sind defekte Blöcke auf der Platte, falsche oder fehlerhafte Verkabelung sowie Probleme mit anderen Komponenten, die am Zugriff auf die Festplatte beteiligt sind. Wenn die Festplatte selbst fehlerhaft sind, sollten Sie entsprechende Meldungen in /var/log/messages und den Ausgaben von dmesg finden. Andernfalls sollten Sie die Kabel und Verbindungen überprüfen.

Der ata(4)-Treiber meldet “UDMA ICRC” Fehler wenn eine DMA-Übertragung zu oder von einem Laufwerk fehlgeschlagen ist. Der Treiber versucht die Übertragung mehrmals durchzuführen und schaltet, wenn die Versuche fehlschlagen, vom DMA-Modus auf den langsameren PIO-Modus um.

Der Fehler kann viele Ursachen haben, häufig ist ein Kabel kaputt oder die Geräte sind falsch verkabelt. Prüfen Sie, ob die ATA-Kabel unbeschädigt sind und für den verwendeten Ultra-DMA-Modus tauglich sind. Ebenso müssen Wechselrahmen für den verwendeten Modus geeignet sein. Stellen Sie sicher, dass alle Kabel fest angeschlossen sind. Es gab auch schon Probleme, wenn ein altes Laufwerk zusammen mit einem Ultra-DMA-66 oder einem schnelleren Laufwerk auf einem Kanal betrieben wurde. Es kann aber auch sein, dass das Laufwerk kaputt ist. Die meisten Hersteller stellen Test-Programme für ihre Laufwerke zur Verfügung. Überprüfen Sie damit Ihr Laufwerk und wenn nötig, sichern Sie Ihre Daten und ersetzen das Laufwerk.

atacontrol(8) zeigt für jedes ATA-Gerät den verwendeten DMA- oder PIO-Modus an. Das Kommando atacontrol mode Kanal zeigt die auf einem Kanal verwendeten Modi (die Kanäle werden von 0 an nummeriert).

Robert Watson <rwatson@FreeBSD.org> hat diese Frage auf der Mailingliste freebsd-current ausführlich beantwortet. Das Original seiner Antwort finden Sie über den Thread “ lock order reversals - what do they mean?”.