|
Häufig gestellte Fragen zu FreeBSD 3.X, 4.X, 5.X und 6.X: Frequently Asked Questions für FreeBSD 3.X, 4.X, 5.X und 6.X | ||
---|---|---|
Zurück | Weiter |
Überhaupt nicht! Lesen Sie den Abschnitt zur Kernelkonfiguration im Handbuch.
Anmerkung: Sie sollten einen datierten Snapshot Ihres Kernels als kernel.YYMMDD zu erstellen, nachdem Sie alles zum Laufen gebracht haben. Außerdem sollten Sie eine Kopie des Verzeichnisses /modules erstellen, die den Namen /modules.YYMMDD hat. Auf diese Weise können Sie diesen Kernel hochfahren, anstatt den ganzen Weg zurück zu kernel.GENERIC gehen zu müssen, wenn Sie das nächste Mal mit Ihrer Konfiguration herumexperimentieren und dabei etwas falsch machen sollten. Das ist besonders wichtig, wenn Sie nun von einem Controller booten, der vom GENERIC-Kernel nicht unterstützt wird.
Lassen Sie mich raten. Sie haben npx0 aus Ihrer Konfigurationsdatei entfernt, weil Sie keinen mathematischen Co-Prozessor besitzen, richtig? Falsch! :-) npx0 ist zwingend erforderlich. Auch, wenn Sie keinen mathematischen Co-Prozessor besitzen, müssen Sie das Gerät npx0 einbinden.
Sie haben Ihren Kernel wahrscheinlich im Debug Modus erstellt. Ein Debug-Kernel enthält viele zusätzliche Informationen für die Fehlersuche, daher ist er so groß. Bitte beachten Sie, dass die Verwendung eines Debug-Kernels bei FreeBSD 3.0 und neueren Version die Performance des Systems nicht oder nur minimal reduziert; außerdem ist es für den Fall einer system panic sehr praktisch, einen Debug-Kernel zur Hand zu haben.
Wenn Ihnen allerdings der Plattenplatz ausgeht oder Sie einfach rein prinzipiell keinen Debug-Kernel benutzen wollen, müssen die beiden folgenden Bedingungen erfüllt sein:
Die Konfigurationsdatei für Ihren Kernel darf die folgende Zeile nicht enthalten:
makeoptions DEBUG=-g
Sie dürfen config(8) nicht mit dem Parameter -g starten.
Sollten Sie sich nicht an diese Einschränkungen halten, wird Ihr Kernel im Debug-Modus erstellt. Solange Sie sich an diese Einschränkungen halten, können Sie Ihren Kernel ganz normal erstellen und die Größe des Kernels sollte deutlich sinken. Ein normaler Kernel ist nur 1.5 MByte bis 2 MByte groß.
8.4. Wieso erhalte ich Meldungen über Interrupt-Konflikte, wenn ich eine Karte mit mehreren seriellen Schnittstellen einsetzen will?
Wenn ich einen Kernel mit Unterstützung für serielle Multi-Port-Schnittstellen kompiliere, bekomme ich den Hinweis, dass nur der erste Port geprüft wird und die restlichen auf Grund von Interrupt-Konflikten übersprungen werden. Wie kann ich das Beheben?
Das Problem besteht darin, dass in FreeBSD Code integriert ist, um den Kernel vor Abstürzen aufgrund von Hardware- oder Software-Konflikten zu bewahren. Behoben wird es, indem die IRQ-Angaben für alle Ports, bis auf einen ausgelassen werden. Hier ist ein Beispiel:
# # Multiport high-speed serial line - 16550 UARTS # device sio2 at isa? port 0x2a0 tty irq 5 flags 0x501 vector siointr device sio3 at isa? port 0x2a8 tty flags 0x501 vector siointr device sio4 at isa? port 0x2b0 tty flags 0x501 vector siointr device sio5 at isa? port 0x2b8 tty flags 0x501 vector siointr
Es gibt eine Reihe von möglichen Ursachen für dieses Problem:
Sie benutzen die neuen Kommandos make buildkernel und make installkernel nicht, obwohl die Sourcen auf Ihrem System nicht zum laufenden System passen (z.B. benutzen Sie die Sourcen von 4.3-RELEASE auf einem System mit 4.0-RELEASE). Wenn Sie ein Upgrade durchführen wollen, sollten Sie /usr/src/UPDATING lesen, beachten Sie insbesondere den Abschnitt “COMMON ITEMS” gegen Ende des Dokuments.
Sie benutzen zwar make buildkernel und make installkernel, aber Sie haben nicht darauf geachtet, dass vorher ein komplettes make buildworld durchgelaufen sein muss. Um seine Arbeit erledigen zu können, benötigt make buildkernel Dateien, die von make buildworld erzeugt werden.
Auch wenn Sie FreeBSD-STABLE verwenden, ist es durchaus möglich, dass Sie die Sourcen genau zum falschen Zeitpunkt aktualisiert haben: Während Sie gerade modifiziert wurden oder kurzzeitig fehlerhaft waren. Eine absolute und vollständige Garantie, dass Sie die Sourcen compilieren können, gibt es nur für die Releases, bei FreeBSD-STABLE ist das nicht immer so. Wenn Sie es noch nicht versucht haben, sollten Sie ihre Source nochmals aktualisieren. Es ist denkbar, dass der von Ihnen genutzte Server zurzeit Probleme hat, benutzten Sie daher testweise auch einmal einen anderen Server.
Wenn Sie FreeBSD 5.2.1 oder älter verwenden, überprüfen Sie dazu, ob auf Ihrem System die sysctl-Variable kern.quantum existiert. Ist dies bei Ihnen der Fall, werden Sie eine Ausgabe ähnlich der folgenden sehen:
% sysctl kern.quantum kern.sched.quantum: 99960
Wenn die sysctl-Variable kern.quantum existiert, dann verwenden Sie den 4BSD-Scheduler. Existiert sie nicht, erzeugt sysctl(8) eine Fehlermeldung (die Sie aber ignorieren können):
% sysctl kern.sched.quantum sysctl: unknown oid 'kern.sched.quantum'
Seit FreeBSD 5.3-RELEASE wird der Name des verwendeten Schedulers direkt als Wert der sysctl-Variable kern.sched.name ausgegeben:
% sysctl kern.sched.name kern.sched.name: 4BSD
kern.quantum ist die maximale Anzahl Ticks, die ein Prozess ununterbrochen laufen kann. Die Variable ist charakteristisch für den 4BSD Scheduler, somit kann der verwendete Scheduler über die Existenz dieser Variablen bestimmt werden. Seit FreeBSD 5.X wird kern.quantum als kern.sched.quantum bezeichnet.
Lesen Sie den Abschnitt F: 8.7.
Zurück | Zum Anfang | Weiter |
Benutzerprogramme | Platten, Dateisysteme und Boot Loader |
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>.