Kapitel 5. Fehlerbehebung

5.1. Warum zeigt FreeBSD eine falsche Speichergröße auf i386™ Hardware an?
5.2. Wieso brechen meine Programme gelegentlich mit Signal 11-Fehlern ab?
5.3. Mein System stürzt mit der Meldung Fatal trap 12: page fault in kernel mode oder panic: ab und gibt eine Menge zusätzlicher Informationen aus. Was kann ich tun?
5.4. Was bedeutet die Fehlermeldung maxproc limit exceeded by uid %i, please see tuning(7) and login.conf(5)?
5.5. Wieso funktionieren bildschirmorientierte Anwendungen beim Zugriff über ein Netzwerk nicht richtig?
5.6. Wieso dauert es so lange, bis eine Verbindung über ssh oder telnet aufgebaut wird?
5.7. Warum sehe ich in der Ausgabe von dmesg(8) häufig die Meldung file: table is full?
5.8. Warum ist die Uhrzeit auf meinem Rechner immer falsch?
5.9. Was bedeutet die Meldung swap_pager: indefinite wait buffer:?
5.10. Was ist ein lock order reversal?
5.11. Was hat die Fehlermeldung Called ... with the following non-sleepable locks held zu bedeuten?
5.12. Warum bricht buildworld/installworld mit der Meldung touch: not found ab?

5.1.

Warum zeigt FreeBSD eine falsche Speichergröße auf i386™ Hardware an?

Das liegt sehr wahrscheinlich an den Unterschieden zwischen physikalischen und virtuellen Speicheradressen.

Bei moderner PC-Hardware ist es üblich, den Speicherbereich zwischen 3,5 und 4 Gigabyte für spezielle Aufgaben (normalerweise für PCI) zu reservieren. Dieser Adressbereich wird dabei verwendet, um auf PCI-Hardware zuzugreifen. Dadurch kann in diesem Speicherbereich kein physikalischer Speicher verwaltet werden.

Was mit dem in diesen Bereich gehörenden physikalischen Speicher passiert, hängt von der eingesetzten Hardware ab. Unglücklicherweise gibt es noch immer Hardware, die hier gar nichts macht. In diesem Fall ist das System nicht in der Lage, auf diese 500 MB des RAMs zuzugreifen.

Ein Großteil der Hardware ist aber inzwischen in der Lage, diesen Speicherbereich in einen höheren Speicherbereich umzulenken, damit Sie weiterhin darauf zugreifen können. Allerdings kann es durch dieses Umlenken zu verwirrenden Meldungen während des Systemstarts kommen.

Unter 32-Bit-Versionen von FreeBSD scheint dieser Speicherbereich nicht verfügbar zu sein, da er in einen Bereich oberhalb von 4 Gigabyte übertragen wurde, auf den ein 32-Bit-Kernel allerdings nicht zugreifen kann. In diesem Fall müssen Sie die PAE-Unterstützung in den Kernel kompilieren. Lesen Sie dazu auch die entsprechenden Einträge über Speicherbegrenzungen und unterschiedliche Speicherbegrenzungen auf verschiedenen Plattformen.

Verwenden Sie hingegen eine 64-Bit-Version von FreeBSD oder einen 32-Bit-Kernel mit aktivierter PAE-Unterstützung, ist FreeBSD in der Lage, diesen Speicherbereich korrekt zu erkennen und umzulenken, damit Sie weiterhin darauf zugreifen können. Allerdings wird, aufgrund der beschriebenen Umbelegung, in diesem Fall beim Systemstart mehr Speicher angezeigt, als tatsächlich auf dem System vorhanden ist. Dies ist aber normal und wird nach dem Ende des Systemstarts automatisch korrigiert.

5.2.

Wieso brechen meine Programme gelegentlich mit Signal 11-Fehlern ab?

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

Das Problem hat in der Regel eine der folgenden Ursachen:

  1. Wenn das Problem nur in einer bestimmten Anwendung auftritt, dann ist es wahrscheinlich ein Fehler im Quellcode.

  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 diese Teile des Codes benutzen können (dafür gibt es schließlich -CURRENT).

Wenn der Fehler auftritt, wenn Sie ein Programm kompilieren 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 Kompilierung von ls.c in ls.o abbricht. Wenn Sie nochmal make buildworld ausführen und die Kompilierung an der gleichen Stelle abbricht, handelt es sich um einen Fehler im Quellcode. Aktualisieren Sie den Code und versuchen Sie es noch einmal. Wenn der Fehler jedoch an einer anderen Stelle auftritt, liegt das Problem mit an Sicherheit grenzender Wahrscheinlichkeit bei der Hardware.

Im ersten Fall können Sie einen Debugger wie z.B. gdb(1) 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 der Hardware verursacht wird.

Typische Ursachen dafür sind:

  1. Es könnte sein, dass die Festplatten zu warm werden: Überprüfen Sie, ob die Lüfter noch funktionieren, damit Festplatten und andere Hardware nicht heißlaufen.

  2. Der Prozessor überhitzt, weil er übertaktet wurde oder der CPU-Kühler ausgefallen ist. Sie müssen sicherstellen, dass Sie die Hardware unter den Bedingungen betreiben, für die sie spezifiziert ist, zumindest 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. Zudem hat die Community wenig Mitgefühl bei Problemen mit übertakteten Systemen.

  3. Unzuverlässiger Speicher: Wenn im Rechner mehr als ein SIMM/DIMM installiert ist, 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 den Einstellungen des BIOS und mit den Jumpern auf dem Mainboard können Sie diverse Timings ändern. In den meisten Fällen reichen die Voreinstellungen 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 Voreinstellungen des BIOS zu laden. Hierbei ist es sinnvoll, vorher die aktuellen Einstellungen zu notieren

  5. Schlechte oder fehlerhafte Stromversorgung des Mainboards: Wenn Sie unbenutzte Steckkarten, Platten oder CD-ROMs in Ihrem System haben, sollten Sie sie testweise ausbauen oder die Stromversorgung abziehen. Dadurch können Sie prüfen, ob das 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 250 W-Netzteil benutzen, sollten Sie testweise ein 300 W-Netzteil einbauen.

Lesen Sie den Abschnitt Signal 11 für weitere Erklärungen. Es existiert eine ausführliche FAQ hierzu unter the SIG11 problem FAQ.

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

5.3.

Mein System stürzt mit der Meldung Fatal trap 12: page fault in kernel mode oder panic: ab und gibt eine Menge zusätzlicher Informationen aus. Was kann ich tun?

Die Entwickler von FreeBSD interessieren sich für solchen Meldungen, allerdings brauchen Sie deutlich mehr Informationen als nur die Fehlermeldung. Kopieren Sie die kompletten Meldungen und lesen Sie anschließend den FAQ-Abschnitt ü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.

5.4.

Was bedeutet die Fehlermeldung maxproc limit exceeded by uid %i, please see tuning(7) and login.conf(5)?

Der FreeBSD-Kernel beschränkt die Anzahl der gleichzeitig laufenden Prozesse. Die Anzahl errechnet sich aus dem Wert der kern.maxusers sysctl(8)-Variable. Auch andere Einstellungen wie die Anzahl der Puffer für Netzwerkoperationen werden durch kern.maxusers beeinflusst. Wenn das System stark belastet ist, sollten Sie den Wert von kern.maxusers erhöhen. Dadurch werden diverse Einstellungen des Systems angepasst und die maximale Anzahl gleichzeitig laufender Prozesse erhöht.

Um den Wert von kern.maxusers anzupassen, folgen Sie den Anweisungen im Abschnitt Datei und Prozeß Limits des Handbuchs. Dieser Abschnitt spricht zwar nur von Dateien, für Prozesse gelten aber die gleichen Beschränkungen.

Wenn das System nicht besonders stark ausgelastet ist und Sie einfach nur mehr gleichzeitig laufende Prozesse erlauben wollen, können Sie den Wert der Variable kern.maxproc in /boot/loader.conf anpassen. Um die Änderung zu aktivieren, müssen Sie das System neu starten. Wollen Sie das System zusätzlich optimieren, sollten Sie loader.conf(5) lesen. 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, weil ein Systemprogramm, init(8), immer ausgeführt werden muss.

5.5.

Wieso funktionieren bildschirmorientierte Anwendungen beim Zugriff über ein Netzwerk nicht richtig?

Die entfernte Maschine scheint den Terminaltyp auf etwas anderes als den Typ xterm, der von FreeBSD verlangt wird, zu setzen. Vielleicht hat aber auch der Kernel falsche Werte für die Breite und Höhe des Terminals.

Überprüfen Sie, ob der Wert der TERM-Umgebungsvariable xterm ist. Wenn das entfernte Gerät dies nicht unterstützt, versuchen Sie vt100.

Führen Sie stty -a aus, um zu überprüfen, was der Kernel für Terminalaußmaße eingestellt hat. Wenn diese Werte falsch sind, können sie mit stty rows RR cols CC geändert werden.

Falls x11/xterm installiert ist, können Sie alternativ auch resize ausführen, um die richtigen Einstellungen für das Terminal zu setzen.

5.6.

Wieso dauert es so lange, bis eine Verbindung über ssh oder telnet aufgebaut wird?

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

Das Problem: In den meisten Fällen versucht der Server 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 in eine Protokolldatei zu schreiben.

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

Wenn das Problem vom Client verursacht wird, müssen Sie die Einträge im DNS korrigieren, damit der Server die IP-Adresse übersetzen kann. Wenn das Problem im lokalen Netzwerk auftritt, sollten Sie es als Problem des Servers behandeln und weiterlesen; wenn es allerdings im Internet auftritt, sollten Sie Ihren ISP kontaktieren.

Wenn das Problem vom Server im lokalen Netzwerk verursacht wird, dann müssen Sie den Server so konfigurieren, dass er die lokal genutzten IP-Adressen in Rechnernamen übersetzen kann. Weitere Informationen finden Sie in 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, ist das System nicht richtig konfiguriert.

Haben Sie FreeBSD gerade erst installiert, kann es auch sein, dass die Domänen- und Nameserverinformationen noch nicht in /etc/resolv.conf vorhanden sind. Dadurch kommt es häufig zu Verzögerungen beim Einsatz von SSH, weil die Option UseDNS in /etc/ssh/sshd_config in der Voreinstellung auf yes gesetzt ist. Wenn dies der Fall, müssen Sie entweder die fehlenden Informationen in /etc/resolv.conf eintragen oder als temporäre Maßnahme UseDNS auf no setzen.

5.7.

Warum sehe ich in der Ausgabe von dmesg(8) häufig die Meldung file: table is full?

Diese Fehlermeldung besagt, dass die zur Verfügung stehenden Datei-Deskriptoren des Systems aufgebraucht sind. Was das genau bedeutet und wie Sie dieses Problem lösen können, steht im Abschnitt kern.maxfiles im Kapitel Einstellungen von Kernel Limits des Handbuchs.

5.8.

Warum ist die Uhrzeit auf meinem Rechner immer falsch?

Der Rechner 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 findet sich in der Zeile mit dem höchsten quality-Wert.

# dmesg | grep Timecounter
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
Timecounter "TSC" frequency 2998570050 Hz quality 800
Timecounters tick every 1.000 msec

Sie können das überprüfen, indem Sie den Wert der sysctl(3)-Variablen kern.timecounter.hardware abfragen.

# sysctl kern.timecounter.hardware
kern.timecounter.hardware: ACPI-fast

Es kann sich um einen defekten ACPI-Timer handeln. Die einfachste Lösung besteht darin, den ACPI-Timer in /boot/loader.conf zu deaktivieren:

debug.acpi.disabled="timer"

Es ist aber auch 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 sysctl(3)-Variable kern.timecounter.hardware geschrieben werden.

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

Die Uhrzeit des Rechners sollte nun genauer funktionieren.

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

kern.timecounter.hardware=i8254

5.9.

Was bedeutet die Meldung swap_pager: indefinite wait buffer:?

Ein Prozess wollte Speicher auf der 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 ist, sollten Sie entsprechende Meldungen in /var/log/messages und der Ausgabe von dmesg finden. Andernfalls sollten Sie die Kabel und Verbindungen überprüfen.

5.10.

Was ist ein lock order reversal?

Der FreeBSD-Kernel benutzt eine Reihe von Ressource-Locks, um den Zugriff auf Ressourcen zu regeln. Wenn verschiedene Kernel-Threads versuchen mehrere Ressource-Locks zu bekommen, besteht immer die Gefahr eines Deadlocks. Hierbei haben zwei Threads einen der Resource-Locks erhalten und blockieren sich nun gegenseitig, weil sie darauf warten, dass der jeweils andere Thread den Resource-Lock wieder freigibt. Diese Art von Locking-Problem kann vermieden werden, indem alle Threads die Locks in der gleichen Reihenfolge erhalten.

In FreeBSD-CURRENT (nicht in STABLE- oder RELEASE-Zweigen) befindet sich das Diagnose-System witness(4), das potentielle Deadlocks in verschiedenen Teilen des Kernels zur Laufzeit erkennt. Das witness(4)-System versucht die Probleme zu erkennen und gibt die Meldung lock order reversal (auch bekannt als LOR) auf der Konsole aus.

Weil witness(4) sehr konservativ vorgeht, ist es ist möglich, ein False Positive (Fehlalarm) zu erhalten. Eine Meldung bedeutet nicht zwangsläufig, dass das System einen Deadlock hat; Stattdessen sollte es als Warnung verstanden werden, dass hier ein Deadlock passiert sein könnte.

Anmerkung:

Problematische LORs werden schnell behoben. Prüfen Sie daher FreeBSD-CURRENT mailing list bevor Sie diese Mailingliste kontaktieren.

5.11.

Was hat die Fehlermeldung Called ... with the following non-sleepable locks held zu bedeuten?

Diese Meldung erscheint, wenn eine Funktion, die sich im Ruhemodus befindet, aufgerufen wird, während ein Mutex oder eine andere (nicht in den Ruhemodus versetzbare) Sperre aktiv war.

Der Grund dafür ist, dass ein Mutex nicht für längere Zeitspannen aktiv sein soll, sondern nur für die Synchronisation von Gerätetreibern mit dem Rest des Kernels während eines Interrupts. Unter FreeBSD dürfen Interrupts nicht in den Ruhemodus versetzt werden. Daher ist es von entscheidender Bedeutung, dass während des Bestehens eines Mutex kein Kernelsubsystem für einen längeren Zeitraum blockiert ist.

Um solche Fehler abzufangen, können Sicherungen (Assertions) in den Kernel eingebaut werden, die danach mit dem witness(4)-Subsystem interagieren. Dadurch wird (in Abhängigkeit der Systemkonfiguration) eine Warnung oder eine Fehlermeldung ausgegeben, falls der Aufruf einer Funktion während des Bestehens eines Mutex zu einer Blockierung führen kann.

Zusammenfassend kann man sagen, dass diese Warnungen in der Regel zwar nicht bedrohlich sind. Unter bestimmten Umständen kann es aber dennoch zu unerwünschten Nebenwirkungen, angefangen von einer Erhöhung der Reaktionszeit bis hin zu einem kompletten Einfrieren des Systems kommen.

Weitere Informationen zum Locking unter FreeBSD finden Sie in locking(9).

5.12.

Warum bricht buildworld/installworld mit der Meldung touch: not found ab?

Dieser Fehler bedeutet nicht, dass touch(1) nicht auf dem System vorhanden ist. Vielmehr sind Dateien die Ursache, deren Erzeugungsdatum in der Zukunft liegt. Wenn die CMOS-Uhr auf die lokale Zeit eingestellt ist, müssen Sie adjkerntz -i verwenden, um die Kerneluhr anzupassen, wenn Sie in den Single-User-Modus booten.

Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an <de-bsd-questions@de.FreeBSD.org>.

Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <de-bsd-translators@de.FreeBSD.org>.