Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 (Tek) 9/12/84; site daemon.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!tektronix!daemon!russg
From: russg@daemon.UUCP (Russel Gorby)
Newsgroups: net.bugs.uucp
Subject: Re: hung line help needed
Message-ID: <85@daemon.UUCP>
Date: Fri, 16-Nov-84 18:40:42 EST
Article-I.D.: daemon.85
Posted: Fri Nov 16 18:40:42 1984
Date-Received: Sun, 18-Nov-84 03:21:24 EST
References: <449@godot.UUCP>
Reply-To: russg@daemon.UUCP (Russel Gorby)
Distribution: net
Organization: Tektronix, Beaverton OR
Lines: 41
Summary: 

In article <449@godot.UUCP> bruce@godot.UUCP (Bruce Nemnich) writes:
>I have been having an awful lot of problems with hung lines with 4.2bsd
>uucp.  By hung, I mean a uucp process sitting blocking on a read from
>the dialout line, but having removed the LCKfile for that line and
>system (presumably after a timeout).  The offending processes must be
>killed by hand.  I breifly looked at the code, but I didn't notice
>anything too bad.  The stack frame at the hung point is often
>main()/conn()/login()/expect()/read(), though sometimes
>main()/imsg()/read().  Any quick fixes?
>-- 
>--Bruce Nemnich, Thinking Machines Corporation, Cambridge, MA
>  ihnp4!godot!bruce, bjn@mit-mc.arpa ... soon to be bruce@godot.arpa


We had that problem here at tektronix also. It only happens when the
uucico session was initiated in answer mode, and the answering modem
is connected to a data switch. I believe that the problem stems from
the fact that the TIOCHPCL call works correctly ( or so I've been told)
under 4.2BSD. The problem is in the disconnect routine in the xqt module
and depending on what defines are set, will hang on either the first
close ( close(0) ) or on the open("/dev/tty",2) which occurs just after
the last close. The reason the hangs occur is that at some point the
dataswitch drops the line, and later uucico tries to do I/O to the
port. At some point in the code DTR get toggled (before the disconnect
routine), which on a dataswitch will cause the connection to be
severed, and DTR to get held low. Any subsequent I/O to the port
will hang because the port won't interrupt any more. This will
cause a hang on the initial close in disconnect(). If this doesn't
get you, then the TIOCHPCL will, because after the last
close ( in disconnect() ), it tries to do the open("/dev/tty",2)
which will hang for the same reason. Our fix (at least for the moment)
was to put a timeout mechanism in the disconnect routine, and this
seems to have fixed that particular problem.

-- 
Russ Gorby
ucbvax!tektronix!russg
(503) 627-1153
Tektronix
PO Box 500 M.S. 19-333
Beaverton OR  97077