*BSD News Article 27187


Return to BSD News archive

Xref: sserve comp.os.386bsd.questions:8665 comp.windows.x.i386unix:7197
Path: sserve!newshost.anu.edu.au!munnari.oz.au!foxhound.dsto.gov.au!fang.dsto.gov.au!yoyo.aarnet.edu.au!news.adelaide.edu.au!basser.cs.su.oz.au!news.cs.su.oz.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.questions,comp.windows.x.i386unix
Subject: Re: Problems with NetBSD-0.9/XFree86-2.0
Date: 10 Feb 1994 01:11:33 +1100
Organization: Kralizec Dialup Unix Sydney - +61-2-837-1183, v.32bis and v.42bis
Lines: 35
Message-ID: <2jaqulINN4q1@godzilla.zeta.org.au>
References: <2j3r5t$34t@newsserv.cs.sunysb.edu> <MIKE.LONG.94Feb7173040@cthulhu.analog.com> <michaelv.760723129@ponderous.cc.iastate.edu>
NNTP-Posting-Host: godzilla.zeta.org.au

In article <michaelv.760723129@ponderous.cc.iastate.edu>,
Michael L. VanLoon <michaelv@iastate.edu> wrote:
>In <MIKE.LONG.94Feb7173040@cthulhu.analog.com> Mike.Long@analog.com (Michael W. Long) writes:
>
>>In article <2j3r5t$34t@newsserv.cs.sunysb.edu> rick@cs.sunysb.edu (Rick Spanbauer) writes:
>
>>>	1.  com0 occasionally hangs kermit/tip in a state that kill -9
>>>	    will not remove them (process state SE+).
>
>>I've had this happen to me.  The com driver is sensitive to XOFF (^S)
>>even when it is told to use RTS/CTS flow control (SET FLOW RTS/CTS in
>>kermit).  ...
>
>I've never experienced this.  Does the *serial port* (not the program)
>know that it's supposed to be ignoring xon/xoff?  Try doing a "stty -f
>/dev/tty00 -ixon -ixoff crtscts" before entering kermit (assuming
>you're using tty00).

For kermit in interactive mode, add also for logins, ixon is normal
so that you can used ^S^Q to stop and start scrolling, while crtscts
helps to avoid going too fast for the modem, so it is normal to have
both on at the same time.  ixoff is for automatic xon-xoff flow
control and you arely want that, especially in conjuction with
crtscts.

When a port is closed, output flow control of all types probably ought
to be ignored (or output ought to be flushed if it is active), so that
ttywait() doesn't hang "forever" waiting for the output to drain.  I
used to have problems with this on old Suns.  My sio driver slill
mishandles at least the crtscts case.  The problem may be more serious
if CLOCAL is set and/or SIGHUPs are being ignored.  I think output is
flushed anyway when carrier drops if SIGHUP kills the process, and
output is discarded if CLOCAL is set and carrier is absent.
-- 
Bruce Evans  bde@kralizec.zeta.org.au