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