*BSD News Article 27679


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!munnari.oz.au!bruce.cs.monash.edu.au!merlin!mel.dit.csiro.au!its.csiro.au!dmssyd.syd.dms.CSIRO.AU!metro!ultima!kralizec.zeta.org.au!godzilla.zeta.org.au!not-for-mail
From: bde@kralizec.zeta.org.au (Bruce Evans)
Newsgroups: comp.os.386bsd.bugs
Subject: Re: Problems with uucico hanging system in FreeBSD-1.0
Date: 21 Feb 1994 12:40:35 +1100
Organization: Kralizec Dialup Unix Sydney - +61-2-837-1183, v.32bis and v.42bis
Lines: 33
Message-ID: <2k93ejINN1ej@godzilla.zeta.org.au>
References: <1994Feb11.031134.11082@sserve.cc.adfa.oz.au> <SWILDNER.94Feb19134150@channelz.gun.de>
NNTP-Posting-Host: godzilla.zeta.org.au

In article <SWILDNER.94Feb19134150@channelz.gun.de>,
Sascha Wildner <swildner@channelz.GUN.de> wrote:
>In article <1994Feb11.031134.11082@sserve.cc.adfa.oz.au> wkt@cserve.cs.adfa.oz.au (Warren Toomey) writes:
>
>   A friend and I are having problems with the Taylor uucico in FreeBSD-1.0
>   literally wedging the system, when collecting email from a remote site with
>...
>Same problem here.  When using uucico with the sio drivers, the system
>will hang after a while or two.  Maybe that's because I'm using 16450s
>only (I haven't gotten around to buying 16550s yet), but this problem
>was definitely introduced with my update to FreeBSD-1.0-GAMMA (the sio
>supplied with 386BSD & pk worked just fine).  On the other hand,

The problem is caused by a flow control bug in sio and a deadlock bug in
ttywait().  The flow control bug results in processes sometimes hanging in
ttywait() (e.g., when they have output to send, but CTS flow control is
enabled and modem has dropped CTS).  This happens quite often when uucico
attempt to exit.  Sometimes another uucico starts up gets stuck in the
same loop in ttywait() (I think when it also attempts to exit).  Having
two processes hanging on the same tty in ttywait() is fatal if the output
buffer is below the low watermark but never empty.  The processes take
turns waking each other up (because the buffer is below the low watermark)
but ttywait() doesn't want to know about that (it expects to be woken up
only when the output buffer is empty).

Both bugs are very old; it's not clear why they didn't matter for the
patchkit version.

The best fix is to wait for FreeBSD-1.1.  You could try programming the
modem to force CTS high, but CTS flow control is essential if the line
speed lower than the tty speed.
-- 
Bruce Evans  bde@kralizec.zeta.org.au