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.
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.
Ü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.
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.
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.
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.
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
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.
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>
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.
Ü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.
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.
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
setserial verwenden, um Linux über den von Ihnen verwendeten IRQ
zu informieren.
Ü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.
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.
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
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).
modemstat und setserial zeigen den aktuellen Zustand
verschiedener Signalleitungen des Modems an (wie z.B. DTR, CTS, etc.)irqtune kann an die von seriellen Ports genutzten
Interrupts eine höhere Priorität vergeben, um die Geschwindigkeit zu
verbessern.hdparm kann helfen, indem Festplattenzugriffe optimiert
werden.