Re: Minicom läßt System einfrieren

From: Bernd Walter <ticso(at)cicely12.cicely.de>
Date: Thu, 11 Dec 2003 18:25:02 +0100

On Thu, Dec 11, 2003 at 04:41:34PM +0100, Patrick Hess wrote:
> Hallo,
>
> Bernd Walter schrieb:
> > On Thu, Dec 11, 2003 at 02:16:06PM +0100, Patrick Hess wrote:
> > tip sio0
> > damit wählst du aus der /etc/remote den Eintrag Namens sio.
>
> Dort gibt es nur den Eintrag com1:
>
> com1:dv=/dev/cuaa0:br#9600:pa=none:

Mmm:
sio0|com1:dv=/dev/cuaa0:br#9600:pa=none:
Aber mag auch sein, daß ich das sio0 davor gesetzt habe.

> Dann habe ich mich mit "tip com1" versucht. Letzte und einzige
> Meldung auf dem Bildschirm war "connected". Danach ging nichts
> mehr.

Das ist doch gut.
Ab jetzt sollten die Zeichen über die seriele rausgehen.
Wenn nichts kommt, dann schickt die Gegenstelle auch nichts.
Wie dem auch sei - wenn der ganze Rechner einfriert, dann hat
die Gegenstelle auch nichts damit zu tun :(

> > Bei cu Syntax cu -l cuaa0 -s 9600
>
> Letzte Meldung ist ebenfalls "connected", dann steht die Kiste.

Bei dem Fehler klar.
Tut denn ein »echo foo > /dev/cuaa0«?
Oder zumindest ein »/bin/true > /dev/cuaa0«?
Letzteres sollte gerade mal die Schnittstelle öffnen und wieder
schließen.
So ein Fall ist mir aber auch noch nicht untergekommen...
Außer halt, wenn was anderes auf der Schnittztelle läuft.
Evtl mal im Single-User Mode testen - dann dürfte ja auch nichts
großartig gestartet worden sein.

> > > Im Übrigen machte der Abschnitt "BUGS" in der cu-Manpage einen
> > > nicht so guten Eindruck :-)
> > > Und so landete ich dann irgendwie bei Minicom...
> >
> > Weil Minicom sein Bugs nicht in der Manpage auflistet?
>
> Naja, es ist wohl schon ein Unterschied, ob ich als Bug schreibe
> "dies und das geht nicht" oder ob da steht "This program does not
> work very well". Das hört sich für mich nach "Finger weg,
> funktioniert nicht" bzw. "(C) Microsoft Corp." an.

Nun - ist wohl wahr, aber letzlich doch harmlos.
Den einzigen unangenehmen Fall den ich kannte war, daß subprozesse
manchmal liegengeblieben sind.
tip und cu benutze 2 Prozesse - einen für den Empfang und einen
fürs Senden.
Besser wäre es eigendlich IO Multiplexing über select und Co zu machen.
Das ist aber inzwischen durch eine bessere Prozesscontrolle erledigt.
Probleme gibt es nur, wenn man einen der beiden per -9 abschließt,
dann hat der keinen Chance mehr sienen Partnerprozess zu informieren.

> Minicom ist jetzt jedenfalls erst mal wieder von der Platte
> geflogen, tip scheint ja an sich die beste Wahl. Nun muß ich nur
> mal gucken, ob ich irgendeinen Anhaltspunkt finde, warum das Ding
> stehen bleibt :-(

Ich bin da auch überfragt.
Wenn ein getty auf der zugehörigen ttyd laufen würde, dann hätte
das schlimmstenfalls Auswirkungen auf den einzelnen tip, aber nicht
aufs gesammte System.

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 11 Dec 2003 - 18:29:21 CET

search this site