Kapitel 5. Fehlerbehebung
Zurück |  | Weiter

## Kapitel 5. Fehlerbehebung

5.1. Warum zeigt FreeBSD eine falsche Speichergröße auf i386™ Hardware an?
5.2. Was sollte ich tun, wenn auf meiner Festplatte fehlerhafte Blöcke sind?
5.3. Wieso wird der SCSI-Controller meines HP Netserver nicht erkannt?
5.4. Was bedeuten die ständigen Meldungen ed1: timeout?
5.5. Warum funktioniert meine 3Com® 3C509 plötzlich nicht mehr?
5.6. Mein an der parallel Schnittstelle angeschlossener Drucker ist unglaublich langsam. Was kann ich tun?
5.7. Wieso brechen meine Programme gelegentlich mit Signal 11-Fehlern ab?
5.8. 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.9. Wieso wird beim Booten der Bildschirm schwarz und reagiert nicht mehr?
5.10. Wieso verwendet FreeBSD nur 64 MB Hauptspeicher, obwohl in meinem Rechner 128 MB sind?
5.11. Ich habe mehr als 1 GB RAM. Trotzdem stürzt mein System mit der Meldung kmem_map too small ab. Was läuft hier schief?
5.12. Ich habe weniger als 1 GB Hauptspeicher. Dennoch stürzt mein System mit der Meldung kmem_map too small ab!
5.13. Wieso erhalte ich die Meldung kernel: proc: table is full?
5.14. Wieso erhalte ich die Meldung CMAP busy panic, wenn ich mein System mit einem neuen Kernel starte?
5.15. Was soll mir die Meldung ahc0: brkadrint, Illegal Host Access at seqaddr 0x0 sagen?
5.16. Wenn ich mein System starte, erhalte ich die Meldung ahc0: illegal cable configuration, obwohl die Verkabelung korrekt ist. Woran liegt das?
5.17. Wieso meldet sendmail mail loops back to myself?
5.18. Wieso funktionieren bildschirmorientierte Anwendungen beim Zugriff über ein Netzwerk nicht richtig?
5.19. Warum wird meine PnP-Karte nicht (oder nur noch als unknown) erkannt?
5.20. Warum erhalte ich die Meldung nlist failed, wenn ich Programme wie top oder systat benutze?
5.21. Wieso dauert es so lange, bis eine Verbindung (ssh(1) oder telnet(1)) aufgebaut wird?
5.22. Was bedeutet stray IRQ?
5.23. Warum sehe ich in der Ausgabe von dmesg(8) häufig die Meldung file: table is full?
5.24. Warum werden ständig Meldungen wie calcru: negative runtime oder calcru: runtime went backwards auf die Konsole geschrieben?
5.25. Warum ist die Uhrzeit auf meinem Computer immer falsch?
5.26. Warum erkennt mein Laptop PC-Cards nicht?
5.27. Wieso hängt sich FreeBSD nach dem BIOS-Bildschirm mit der Meldung Read error auf?
5.28. Ein anderes Betriebssystem hat meinen Bootmanager zerstört. Wie kann ich ihn wiederherstellen?
5.29. Was soll mir die Meldung swap_pager: indefinite wait buffer: sagen?
5.30. Was sind UDMA ICRC Fehler und wie behebe ich sie?
5.31. Was ist ein lock order reversal?
5.32. Warum erhalte ich die Meldung Called ... with the following non-sleepable locks held?
5.33. 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 Speicheraddressen.

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 dazu 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 von Ihnen eingesetzten Hardware ab. Unglücklicherweise gibt es noch immer Hardware, die hier gar nichts macht. In diesem Fall ist Ihr System nicht in der Lage, auf diese 500 Megabyte des RAMs zuzugreifen.

Ein Großteil der heute existierenden 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 verwirrende 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. Ist dies bei Ihnen der Fall, müssen Sie die PAE-Unterstützung in Ihren 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 Ihrem System vorhanden ist. Dies ist aber normal und wird nach dem Ende des Systemstarts automatisch korrigiert.

5.2. | Was sollte ich tun, wenn auf meiner Festplatte fehlerhafte Blöcke sind?

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

Moderne IDE-Controller sind in der Lage, fehlerhafte Blöcke automatisch zu verlagern. Diese Funktionen sind bereits ab Werk aktiviert.

Werden dennoch fehlerhafte Blöcke gemeldet (egal auf welchem Laufwerk), sollten Sie über den Kauf einer neuen Platte nachdenken. Zwar könnte es Ihnen mit Diagnoseprogrammen des Plattenherstellers gelingen, diese fehlerhaften Blöcke zu sperren. Allerdings können Sie damit den endgültigen Ausfall der Platte bestenfalls hinauszögern.

5.3. | Wieso wird der SCSI-Controller meines HP Netserver nicht erkannt?

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 den folgenden Befehl am Prompt ein und Sie können Ihr System ganz normal installieren:

eisa 12 quit

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.

### Anmerkung:

Sie können keine `dangerously dedicated` Platte auf einem HP Netserver verwenden. Lesen Sie weitere Informationen finden Sie in diesem Hinweis.

5.4. | Was bedeuten die ständigen Meldungen `ed1: timeout`?

Dies wird meistens durch einen Interruptkonflikt verursacht (z.B., wenn zwei Karten den selben Interrupt benutzen). Booten Sie mit der Option `-c` und ändern Sie die Einträge zu `ed0`/`de0`/... (d.h. 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.

5.5. | Warum funktioniert meine 3Com® 3C509 plötzlich nicht mehr?
| Diese Karte ist dafür berüchtigt, ihre Konfiguration zu vergessen. Sie müssen die Karte mit dem DOS-Programm `3c5x9.exe` neu konfigurieren.
5.6. | Mein an der parallel Schnittstelle angeschlossener Drucker ist unglaublich langsam. Was kann ich tun?
| 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.
5.7. | 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 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(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 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, 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. 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 CD-ROMs 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 250 W-Netzteil benutzen, sollten Sie testweise ein 300 W-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.

5.8. | 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 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.

5.9. | Wieso wird beim Booten der Bildschirm schwarz und reagiert nicht mehr?

Dies ist ein bekanntes Problem mit der ATI Mach64 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(4)-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/sio/sio.c` (oder in `/usr/src/sys/pc98/cbus/sio.c` für pc98) 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.

5.10. | Wieso verwendet FreeBSD nur 64 MB Hauptspeicher, obwohl in meinem Rechner 128 MB sind?

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 = 64 MB) erkennen (oder weniger... einige BIOSe setzen die Hauptspeichergröße auf 16 MB). Falls Sie mehr als 64 MB 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.

5.11. | Ich habe mehr als 1 GB RAM. Trotzdem stürzt mein System mit der Meldung kmem_map too small ab. Was läuft hier schief?

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.

5.12. | Ich habe weniger als 1 GB Hauptspeicher. Dennoch stürzt mein System mit der Meldung kmem_map too small ab!
| 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 den Anweisungen des Abschnitts Netzwerk-Limits des Handbuchs folgen.
5.13. | Wieso erhalte ich die Meldung kernel: proc: table is full?

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.

Um den Wert von `MAXUSERS` anzupassen, folgen Sie den Anweisungen des Abschnitts Datei- und Prozesslimits des Handbuchs. Dieser Abschnitt spricht zwar nur von Dateien, für Prozesse gelten aber die gleichen Beschränkungen.

Wenn Ihr 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 der Datei `/boot/loader.conf` anpassen. Um die Änderung zu aktivieren, müssen Sie Ihr System neu starten. Wollen Sie Ihr System zusätzlich optimieren, sollten Sie loader.conf(5) und sysctl.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` (der Grund für diese Einschränkung ist, dass ein Systemprogramm, init(8), immer ausgeführt werden muss).

Damit Änderungen einer sysctl-Variable dauerhaft erhalten bleiben, nehmen Sie diese in `/etc/sysctl.conf` auf. Weitere Informationen zur Optimierung Ihres Systems finden Sie im Abschnitt Einstellungen mit sysctl des Handbuchs.

5.14. | Wieso erhalte ich die Meldung CMAP busy panic, wenn ich mein System mit einem neuen Kernel starte?
| 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 in den Single-User-Modus und löschen Sie die Dateien: `#` `rm /var/db/kvm_*.db`
5.15. | Was soll mir die Meldung ahc0: brkadrint, Illegal Host Access at seqaddr 0x0 sagen?
| 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.
5.16. | Wenn ich mein System starte, erhalte ich die Meldung ahc0: illegal cable configuration, obwohl die Verkabelung korrekt ist. Woran liegt das?

Auf Ihrem Mainboard fehlen ein paar Logikbausteine, 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 ahc(4)-Treiber 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.

5.17. | Wieso meldet sendmail mail loops back to myself?
| Sie finden eine detaillierte Antwort auf diese Frage im Handbuch.
5.18. | Wieso funktionieren bildschirmorientierte Anwendungen beim Zugriff über ein Netzwerk nicht richtig?

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-Konsole. 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.

5.19. | Warum wird meine PnP-Karte nicht (oder nur noch als `unknown`) erkannt?

Die Gründe für dieses Verhalten werden in der unten zitierten Mail von Peter Wemm erklärt. Diese Mail stammt von der Mailingliste FreeBSD general 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.

### Anmerkung:

Die mit `[]` gekennzeichneten Kommentare wurden eingefügt, um an einigen Stellen die Bezüge klarzustellen.

> 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-Erkennungsroutine 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 am 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 `Vendor ID` oder `chip`-ID müssen in die Datei `/usr/src/sys/dev/sio/sio_isa.c` eingetragen werden.

Sie sollten zunächst ein Backup von `sio_isa.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_isa.c` mit einem Editor und suchen Sie nach der Zeile:

static struct isa_pnp_id sio_ids[] = {

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 als `sio` Gerät erkannt werden.

5.20. | Warum erhalte ich die Meldung nlist failed, wenn ich Programme wie `top` oder `systat` benutze?

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.

5.21. | Wieso dauert es so lange, bis eine Verbindung (ssh(1) oder telnet(1)) 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) 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.

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 der Voreinstellung auf `yes` gesetzt ist (in der Datei `sshd_config` im Verzeichnis `/etc/ssh`). Ist dies bei Ihnen 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.22. | Was bedeutet stray IRQ?

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 den Wert von `MAX_STRAY_LOG` von `5` auf `0` in der für ihre Plattform (z.B. i386™) zuständigen Datei `intr_machdep.c` ändern. Bauen Sie anschliessend den Kernel neu, 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.

5.23. | Warum sehe ich in der Ausgabe von dmesg(8) häufig die Meldung file: table is full?
| 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.
5.24. | Warum werden ständig Meldungen wie calcru: negative runtime oder calcru: runtime went backwards auf die Konsole geschrieben?

Es existiert ein bekanntes Problem wenn Intel® Enhanced SpeedStep im BIOS aktiviert wird. Das führt dazu, dass der Kernel calcru-Nachrichten wie die folgende ausgibt:

calcru: runtime went backwards from 6 usec to 3 usec for pid 37 (pagezero) calcru: runtime went backwards from 6 usec to 3 usec for pid 36 (vmdaemon) calcru: runtime went backwards from 170 usec to 138 usec for pid 35 (pagedaemon) calcru: runtime went backwards from 553 usec to 291 usec for pid 15 (swi6: task queue) calcru: runtime went backwards from 15521 usec to 10366 usec for pid 2 (g_event) calcru: runtime went backwards from 25 usec to 12 usec for pid 11 (swi1: net) calcru: runtime went backwards from 4417 usec to 3960 usec for pid 1 (init) calcru: runtime went backwards from 2084385 usec to 1793542 usec for pid 1 (init) calcru: runtime went backwards from 408 usec to 204 usec for pid 0 (swapper)

Der Grund dafür besteht darin, dass Intel® SpeedStep (EIST) in manchen Mainboards inkompatibel ist.

Abhilfe: Deaktivieren Sie die EIST-Eigenschaft im BIOS. Sie können trotzdem noch ihre Prozessorfrequenz ACPI-basiert mittels powerd(8) drosseln.

5.25. | Warum ist die Uhrzeit auf meinem Computer immer falsch?

Ihr Computer 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 Systemvariablen `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 Systemvariable `kern.timecounter.hardware` geschrieben werden.

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

Die Uhrzeit Ihres Computers 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

5.26. | Warum erkennt mein Laptop PC-Cards nicht?

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(8) 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.

5.27. | Wieso hängt sich FreeBSD nach dem BIOS-Bildschirm mit der Meldung Read error auf?

Der Bootloader von FreeBSD erkennt die Geometrie Ihrer Festplatte nicht richtig. Sie müssen die Geometrie manuell festlegen, wenn sie mit fdisk(8) 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.

5.28. | Ein anderes Betriebssystem hat meinen Bootmanager zerstört. Wie kann ich ihn wiederherstellen?
| 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.
5.29. | Was soll mir die Meldung swap_pager: indefinite wait buffer: sagen?

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.

5.30. | Was sind UDMA ICRC Fehler und wie behebe ich sie?

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).

5.31. | Was ist ein lock order reversal?
| Eine Antwort auf diese Frage findet sich im FreeBSD-Glossar unter LOR.
5.32. | Warum erhalte ich die Meldung Called ... with the following non-sleepable locks held?

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 von Ihrer 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.

5.33. | Warum bricht `buildworld`/`installworld` mit der Meldung touch: not found ab?
| Dieser Fehler bedeutet nicht, dass touch(1) nicht auf Ihrem System vorhanden ist. Vielmehr sind Dateien die Ursache, deren Erzeugungsdatum in der Zukunft liegt. Wenn Ihre CMOS-Uhr auf Ihre lokale Zeit eingestellt ist, müssen Sie `adjkerntz -i` verwenden, um die Kerneluhr anzupassen, wenn Sie in den Single-User-Modus booten.

Zurück |  | Weiter
4.8. Sonstige Hardware | Zum Anfang | Kapitel 6. Kommerzielle Anwendungen

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>.