Inhalt

14. Fehlerursachen erkennen und beheben

14.1 Mit meinem 56k Modem erreiche ich keine 56k

Die Qualität der Telefonleitung muss schon sehr gut sein, um auch nur in die Nähe von 56k zu gelangen. Einige Telefonleitungen sind so schlecht, dass die erreichbare Geschwindigkeit weit unterhalb von 56k liegt: z.B. bei 28,8k oder noch weiter darunter. Manchmal können zusätzliche Telefonapparate, die an die selbe Leitung angeschlossen sind, Probleme verursachen.

14.2 Dateiübertragungen werden abgebrochen oder sind langsam

Eventuell ist die Flusskontrolle (sowohl am PC als auch am Modem) nicht aktiviert. Wenn Sie eine hohe DTE Geschwindigkeit (z.B. 115,2 kbps) eingestellt haben, dann kann der Datenfluss von Ihrem Modem zum PC gut funktionieren, aber in der anderen Übertragungsrichtung bildet die Telefonleitung einen Flaschenhals. Das Ergebnis sind viele Übertragungsfehler und daher müssen viele Datenpakete wiederholt gesendet werden. Es kann daher sehr lange dauern, eine Datei zu senden. Manchmal ist eine Dateiübertragung auch gänzlich unmöglich. Wenn Sie große, nicht komprimierte Dateien oder Internetseiten herunterladen und Ihr Modem verwendet Datenkompression, oder wenn Sie eine geringe DTE Geschwindigkeit eingestellt haben, dann kann das Herunterladen auch abgebrochen werden, weil die Flusskontrolle fehlt.

14.3 Bei Verwendung von getty erhalte ich die Meldung »line NNN of inittab invalid«

Überprüfen Sie, dass die verwendete Syntax für Ihre Version von init stimmt. Unterschiedliche Version von init setzen auch eine unterschiedliche Syntax in der Datei /etc/inittab voraus. Überprüfen Sie auch, ob die Syntax für Ihre Version von getty richtig ist.

14.4 Beim Verbindungsaufbau erscheint die Meldung »/dev/ttySN: Device or resource busy«

Dieses Problem kann auftauchen, wenn die Steuerung der Signale DCD oder DTR nicht richtig implementiert ist. Das DCD Signal sollte nur dann gesetzt sein, wenn eine Verbindung aufgebaut ist (z.B. wenn sich jemand eingewählt hat), und nicht wenn getty den entsprechenden Port überwacht. Überprüfen Sie, dass das Modem so konfiguriert ist, dass es nur dann das DCD signalisiert, wenn eine Verbindung besteht. Das DTR Signal sollte immer dann gesetzt sein, wenn ein Programm den Port überwacht, z.B. getty, kermit oder ein anderes Terminalprogramm.

Eine andere häufige Ursache für einen »device busy«-Fehler besteht in der fehlerhaften Zuordnung eines IRQ an einen seriellen Port, der bereits von einem anderen Gerät verwendet wird. Wenn die Peripheriegeräte initialisiert werden, holen sie sich von Linux die Berechtigung, ihren eingestellten Hardware Interrupt zu verwenden. Linux verwaltet die Informationen, welcher Interrupt von welcher Hardware verwendet wird, und wenn der Interrupt der seriellen Schnittstelle bereits vergeben wurde, kann sich die serielle Schnittstelle nicht richtig initialisieren. Dabei hat sie kaum die Möglichkeit, Ihnen mitzuteilen, dass die Intitialisierung fehlgeschlagen ist, ausser bei dem Versuch, sie zu verwenden, indem sie die »device busy« Meldung ausgibt. Überprüfen Sie die IRQs aller Geräte (serielle Schnittstelle, Ethernet Adapter, SCSI Controller etc). Achten Sie auf IRQ Konflikte.

14.5 Es erscheint die Meldung »Id S3 respawning too fast: disabled for 5 minutes«

Id S3 ist hier nur ein beispielhafter Wert. Suchen Sie in der Datei /etc/inittab nach der Zeile, die mit »S3« beginnt. Diese Zeile verursacht das Problem. Überprüfen Sie diese Zeile auf korrekte Syntax, und überprüfen Sie, dass das Gerät ttyS3 existiert und gefunden werden kann.

Stellen Sie auch sicher, dass Ihr Modem richtig konfiguriert ist. Überprüfen Sie die Einstellung der Register »E« und »Q«. Das Problem kann auftreten, wenn das Modem mit getty kommuniziert.

Wenn Sie uugetty verwenden, überprüfen Sie die Syntax der Datei /etc/gettydefs mit dem Befehl 

getty -c /etc/gettydefs

Dieses Problem kann auch auftauchen, wenn die Initialisierung von uugetty fehlschlägt; siehe auch uugetty funktioniert noch immer nicht.

14.6 Mein Modem spielt nach dem Verbindungsende verrückt, oder uugetty startet nicht wieder

Das kann passieren, falls Ihr Modem sich nicht zurücksetzt, wenn das DTR Signal verschwindet. Greg Hankins hat beobachtet, wie die RD und SD LEDs in dieser Situation verrückt gespielt haben. Sie müssen Ihr Modem zurücksetzen. Bei den meisten Hayes-Kompatiblen Modems geht das mit dem Befehl »&D3«, aber bei einem USR Courier Modem brauchen Sie den Befehl »&D2« und »S13=1«. Schlagen Sie den Reset-Befehl im Modem-Handbuch nach.

14.7 uugetty funktioniert noch immer nicht

Zu getty_ps gibt es eine »Debug«-Option. Erweitern Sie die Konfigurationsdatei /etc/conf.{uu}getty.ttyS und fügen Sie die Option »DEBUG=NNN« hinzu. Dabei bedeutet »NNN« eine der folgenden Ziffernkombinationen, je nachdem, was Sie untersuchen wollen: 

D_OPT   001            Einstellung der Optionen
D_DEF   002            Standard-Dateiverarbeitung
D_UTMP  004            utmp/wtmp Verarbeitung
D_INIT  010            Leitungsinitialisierung (INIT)
D_GTAB  020            gettytab Dateiverarbeitung
D_RUN   040            andere Diagnosehilfsmittel
D_RB    100            Fehlersuche über Rückruffunktion
D_LOCK  200            uugetty Sperrdatei Verarbeitung
D_SCH   400            Verarbeitung der Zeitzuordnung
D_ALL   777            alles zusammen
Setzen Sie zu Anfang die Option »DEBUG=010«.

Falls Sie syslogd verwenden, werden Hinweise zur Fehlersuche in die Protokolldateien geschrieben. Falls Sie syslogd nicht verwenden, werden Debugging-Informationen von getty in der Datei /tmp/getty::ttySN und von uugetty in /tmp/uugetty::ttySN und in /var/adm/getty.log protokolliert. Sehen Sie sich diese Informationen an und finden Sie heraus, was passiert. Wahrscheinlich müssen Sie einige Parameter in den Konfigurationsdateien anpassen und Ihr Modem umkonfigurieren.

Sie können es ja auch mal mit mgetty probieren. Manchmal hat man damit mehr Glück.

14.8 Mein Modem ist zwar physisch vorhanden, kann aber nicht gefunden werden

Falls Sie die seriellen Ports kannten, die vor der Installation des internen Modems existierten, dann besteht das Problem darin, den neuen seriellen Port zu finden. Dies wird im nächsten Abschnitt behandelt. In diesem Abschnitt soll es darum gehen, wie man herausfindet, an welchem seriellen Port das Modem angeschlossen ist.

Es gibt ein Programm namens wvdialconf, das die üblicherweise verwendeten seriellen Ports auf ein angeschlossenes Modem überprüft. Geben Sie einfach ein: 

wvdialconf <ein-neuer-Dateiname>
Die neu angelegte Datei ist eine Konfigurationsdatei für wvdial, sie benötigen diese Datei, wenn Sie wvdial einsetzen wollen; siehe auch Was ist wvdialconf?.

Vielleicht liegt Ihr Problem darin begründet, dass Sie ein Winmodem verwenden, welches unter Linux nicht verwendet werden kann. Siehe auch Interne Modems, die zu meiden sind. setserial kann zwar verwendet werden, um Informationen über serielle Ports herauszufinden, aber nicht, ob an einem seriellen Port auch ein Modem angeschlossen ist. Sie sollten es daher zunächst mit wvdialconf versuchen.

Eine andere Möglichkeit um herauszufinden, ob an einem Port ein Modem angschlossen ist, besteht darin, minicom auf diesem Port zu starten (mit dem Befehl »^A0« gelangen Sie in das Menü mit den Konfigurationseinstellungen). Geben Sie »AT« ein, und Sie sollten ein »OK« zurückerhalten (bzw. eine »0«, falls das Modem auf numerische Antwortcodes eingestellt ist). Wenn es einige Sekunden dauert, bis Sie eine Antwort erhalten oder wenn sich lediglich der Cursor um eine Zeile nach unten bewegt, sehen Sie im Abschnitt Text erscheint auf dem Bildschirm langsam und nach langer Verzögerung nach.

14.9 Der serielle Port ist physisch vorhanden, kann aber nicht gefunden werden

Überprüfen Sie die BIOS Einstellungen und die Meldungen des BIOS. Wenn es sich um einen seriellen PnP-Port für den ISA Bus handelt, können Sie es mit dem Befehl 

pnpdump --dumpregs

versuchen und/oder im Plug-and-Play HOWTO nachsehen. Beim PCI Bus sollten Sie einen Blick in die Datei /proc/pci werfen. Sie können mit Hilfe von setserial ein Probing durchführen, siehe auch Probing. Falls keinerlei Daten über den Port ausgetauscht werden können, obwohl er vorhanden ist, liegt es eventuell an einem falschen Interrupt, siehe auch Text erscheint auf dem Bildschirm langsam und nach langer Verzögerung.

14.10 Text erscheint auf dem Bildschirm langsam und nach langer Verzögerung

Wahrscheinlich liegt die Ursache in einem falsch eingestellten Interrupt oder einem IRQ Konflikt. Im folgenden sind einige der Symptome beschrieben, die bei dem Versuch auftreten, zum ersten Mal ein Modem, ein Terminal oder einen Drucker zu verwenden.

Weitere Informationen über die Symptome und Gründe für diese Verhaltensweisen finden Sie im (englischen) Serial HOWTO im Kapitel »Interrupt Problem Details«.

Um sicherzugehen, dass es sich wirklich um ein Interrupt-Problem handelt, können Sie den IRQ mit Hilfe von setserial auf Null einstellen. Der Gerätetreiber wird dadurch angewiesen, statt eines Interrupts das sogenannte Polling zu verwenden (mit Hilfe von Interrupts kann ein Gerät die CPU auf sich aufmerksam machen, wenn z.B. Daten zum Lesen anstehen, während bei der Polling-Methode die CPU von sich aus regelmäßig am Gerät prüft, ob Daten vorhanden sind. In der Alltagswelt hat z.B. Ihre Türklingel die Funktion eines Interrupt. Hätten Sie keine Türklingel und wollen keinen Besucher verpassen, müßten Sie alle paar Sekunden zur Türe gehen und nachsehen, ob jemand davorsteht. Klar, dass Polling ziemlich ineffektiv ist). Wenn das Ihr Problem behebt, liegt die Ursache in einem falschen Interrupt. Sie sollten auf jeden Fall versuchen, die IRQs richtig zu konfigurieren, denn das Polling benötigt extrem viel Resourcen des Rechners.

Einen Interrupt-Konflikt zu finden, ist nicht immer einfach. Auch ein Blick in das /proc-Verzeichnis kann u.U. täuschen. Stellen Sie sicher, dass kein IRQ unerlaubterweise gemeinsam genutzt wird. Überprüfen Sie alle Steckkarten (serielle Karte, Netzwerkkarte, SCSI, usw). Überprüfen Sie die Jumper- (oder PnP-)Einstellungen und die setserial-Parameter für alle seriellen Geräte. Überprüfen Sie auch die Dateien /proc/ioports, /proc/interrupts und /proc/pci auf Interrupt-Konflikte. Weitere Informationen zu diesem Thema finden Sie im (englischen) Serial HOWTO, Kapitel »Interrupt Problem Detail«. Informationen bei Verwendung von PnP-Hardware finden Sie auch im Plug-and-Play HOWTO.

14.11 Der Startbildschirm zeigt falsche IRQ-Werte für die seriellen Ports

Beim Systemstart versucht Linux nicht, die richtige Belegung der IRQs herauszufinden. Beim Laden des Gerätetreiber-Moduls für den seriellen Port wird nur das serielle Gerät überprüft. Die zu diesem Zeitpunkt ausgegebenen Meldungen können Sie bezüglich des IRQs ignorieren, weil der Gerätetreiber immer von der Standardbelegung der IRQs ausgeht. Die automatische Erkennung von IRQs ist unzuverlässig und schlägt häufig fehl. Wenn aber setserial von einem Startskript aufgerufen wird, werden die IRQs geändert und die neuen und hoffentlich richtigen Werte werden auf dem Startbildschirm ausgegeben. Wenn also ein falscher IRQ bei einer späteren Ausgabe nicht korrigiert wird, haben Sie ein Problem.

Obwohl ich den IRQ für ttyS2 auf den IRQ 5 eingestellt habe, sehe ich 

ttyS02 at 0x03e8 (irq = 4) is a 16550A
auf dem Bildschirm, wenn Linux bootet (bei älteren Kernelversionen kann »ttyS02« evtl. als »tty02« angezeigt werden). Sie müssen setserial verwenden, um Linux über den von Ihnen verwendeten IRQ zu informieren.

14.12 »Cannot open /dev/ttyS?: Permission denied«

Überprüfen Sie die Dateirechte für die seriellen Ports mit dem Befehl 

ls -l /dev/ttyS?

Sie benötigen Lese- und Schreibberechtigung. Die Rechte sollten in Spalte 8 und 9 auf »rw-« gesetzt sein, dies ermöglicht jedem den Zugriff auf den Port. Mit dem Befehl chmod können Sie die Rechte verändern. Häufig sind Lese- und Schreibrecht auch nur für eine bestimmte Benutzergruppe z.B »uucp« gesetzt; Sie müssen dann mit Ihrer Benutzerkennung Mitglied dieser Gruppe sein, um Zugriff auf die seriellen Ports zu erhalten.

14.13 Fehlermeldung für ttySx: »Operation not supported by device«

Dies bedeutet, dass eine von setserial, stty, etc. ausgelöste Operation nicht durchgeführt werden konnte, weil dies der Kernel nicht unterstützt. Früher war dies oft der Fall, wenn das Modul für den seriellen Gerätetreiber nicht geladen war. Aber bei Verwendung von PnP-Karten bedeutet die Meldung wahrscheinlich, dass sich an der Adresse, von der der Gerätetreiber (und setserial) ausgeht, kein Modem (oder ein anderes serielles Gerät) befindet. Befehle, die zu dieser Adresse übertragen werden, können dann natürlich nicht ausgeführt werden. Siehe auch Wie ist die Hardware des seriellen Ports eingestellt?.

Falls das Modul für den seriellen Gerätetreiber nicht geladen wurde, aber lsmod anzeigt, dass dieses Modul geladen ist, dann kann es sein, dass das Modul zum Zeitpunkt der Fehlermeldung nicht geladen war. In den meisten Fällen wird dieses Modul automatisch geladen, wenn es benötigt wird. Um das Laden des Moduls zu erzwingen, kann es in die Datei /etc/modules.conf oder /etc/modules eingetragen werden. Das Modul selbst sollte sich unter /lib/modules/.../misc/serial.o befinden.

14.14 Fehlermeldung »Cannot create lockfile. Sorry«

Wenn ein Port durch ein Programm geöffnet wird, wird zugleich eine Sperrdatei im Verzeichnis /var/lock/ angelegt. Sind die Rechte für dieses Verzeichnis falsch eingestellt, kann keine Sperrdatei erzeugt werden. Mit dem Befehl 

ls -ld /var/lock
können Sie die Berechtigungen anzeigen lassen, normalerweise sollte »drwxrwxrwx« eingestellt sein. Mit dem Befehl chmod können Sie die Berechtigungen ändern. Und natürlich kann auch keine Sperrdatei angelegt werden, wenn das Lock-Verzeichnis nicht existiert. Weitere Informationen über Sperrdateien finden Sie im Serial HOWTO im Kapitel »What Are Lock Files« (in Englisch).

14.15 Hilfreiche Software

Inhalt

Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 17:56:55