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:
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 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:
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 Um den Wert von 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 | |
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 Überprüfen Sie, ob der Wert der Führen Sie Falls x11/xterm installiert ist, können Sie alternativ auch | |
5.6. | Wieso dauert es so lange, bis eine Verbindung über |
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. Haben Sie FreeBSD gerade erst installiert, kann es auch sein, dass die Domänen- und Nameserverinformationen noch nicht in | |
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
Sie können das überprüfen, indem Sie den Wert der sysctl(3)-Variablen
Es kann sich um einen defekten ACPI-Timer handeln. Die einfachste Lösung besteht darin, den ACPI-Timer in 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
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 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 | |
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 |
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 |
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>.