18.1. | Wie kann ich mehr über die Interna von FreeBSD erfahren? |
Lesen Sie das FreeBSD Architecture Handbook. Allgemeines Wissen über UNIX® kann allerdings in den meisten Fällen auf FreeBSD angewendet werden. | |
18.2. | Wie kann ich bei der Entwicklung von FreeBSD mithelfen? |
Genauere Informationen finden Sie im Artikel FreeBSD unterstützen. Wir können Hilfe immer gut gebrauchen! | |
18.3. | Was sind Snapshots und Releases? |
Derzeit existieren drei aktive/halbaktive Zweige im FreeBSD Subversion Repository. In früheren Zweigen ändert sich wenig, daher gibt es nur drei aktive Entwicklungszweige:
Derzeit steht -CURRENT für den 11. | |
18.4. | Ich habe eine Kernelerweiterung geschrieben. An wen sende ich sie? |
Lesen Sie den Artikel FreeBSD unterstützen. Und Danke, dass Sie darüber nachdenken! | |
18.5. | Wie kann ich optimalen Nutzen aus einer kernel panic ziehen? |
Hier ist eine typische Kernel-Panic: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x40 fault code = supervisor read, page not present instruction pointer = 0x8:0xf014a7e5 stack pointer = 0x10:0xf4ed6f24 frame pointer = 0x10:0xf4ed6f28 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 80 (mount) interrupt mask = trap number = 12 panic: page fault Bei Meldungen wie dieser, reicht es nicht, sie einfach zu reproduzieren und sie einzusenden. Der Wert des Instruktionszeigers ist wichtig; leider ist er auch konfigurationsabhängig. Mit anderen Worten variieren die Werte abhängig von dem Kernel-Image, das Sie tatsächlich benutzen. Wenn Sie ein Was Sie tun sollten, ist folgendes:
Wie dem auch sei, der beste Weg, den Grund für eine Panik herauszufinden, ist der, einen Crash-Dump festzuhalten und dann kgdb(1) zu benutzen, um den Stack im Crash-Dump zurückzuverfolgen. Jedenfalls funktioniert die Methode wie folgt:
Anmerkung:Falls Sie Der make(1)-Prozess wird zwei Kernel erstellen: Damit ein Crash-Dump erhalten bleibt, müssen Sie Anmerkung:FreeBSD Crash-Dumps sind für gewöhnlich genauso groß wie der physikalische Hauptspeicher des Rechners. Deshalb müssen Sie dafür sorgen, dass genügend Speicherplatz in Sobald der Crash-Dump wiederhergestellt wurde, können Sie den Stack zurückverfolgen:
Beachten Sie, dass es mehrere Seiten mit wertvollen Informationen geben könnte; idealerweise sollten Sie script(1) benutzen, um sie alle festzuhalten. Wenn Sie das vollständige Kernelimage mit allen Debugginginformationen benutzen, müssten Sie exakt die Zeile des Kernel-Quellcodes finden, wo die Panik aufgetreten ist. Für gewöhnlich müssen Sie den Stack von unten an zurückverfolgen, um die genaue Ereignisabfolge, die zum Crash führte, zurückzuverfolgen. Sie können kgdb(1) auch zum Ausdrucken der Inhalte verschiedener Variablen oder Strukturen benutzen, um den Systemstatus zum Zeitpunkt des Absturzes zu untersuchen. Tipp:Wenn Sie einen zweiten Rechner haben, können Sie kgdb(1) auch für entferntes Debugging konfigurieren, einschließlich dem Setzen von Haltepunkten und dem Bewegen in Einzelschritten durch den Kernelcode. Anmerkung:Wenn Sie | |
18.6. | Wieso funktioniert |
Die ELF-Werkzeuge machen die in einem Executable definierten Symbole dem dynamischen Linker nicht standardmäßig sichtbar. Konsequenterweise werden Wenn Sie mit | |
18.7. | Wie kann ich den Adressraum des Kernels auf i386 vergrössern oder verkleinern? |
Standardmäßig beträgt der Adressraum des Kernels 1 GB (2 GB für PAE) auf i386. Wenn Sie einen netzwerkintensiven Server oder ZFS verwenden möchten, kann es sein, dass dies nicht ausreichend ist. Fügen Sie die folgende Zeile zur Kernelkonfigurationsdatei hinzu, um den verfügbaren Speicher zu erhöhen und erstellen Sie dann einen neuen Kernel: options KVA_PAGES= Um den richtigen Wert von |
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>.