Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:8603 comp.windows.x.i386unix:7130 Newsgroups: comp.os.386bsd.questions,comp.windows.x.i386unix Path: sserve!newshost.anu.edu.au!munnari.oz.au!uunet!MathWorks.Com!noc.near.net!analog.com!analog.com!nwd2sun2.analog.com!Mike.Long From: Mike.Long@analog.com (Michael W. Long) Subject: Re: Problems with NetBSD-0.9/XFree86-2.0 In-Reply-To: michaelv@iastate.edu's message of 08 Feb 1994 10:58:49 -0500 Message-ID: <MIKE.LONG.94Feb10173126@cthulhu.analog.com> Lines: 38 Sender: usenet@analog.com Reply-To: Mike Long <Mike.Long@Analog.com> Organization: Analog Devices Inc, Norwood MA, USA References: <2j3r5t$34t@newsserv.cs.sunysb.edu> <MIKE.LONG.94Feb7173040@cthulhu.analog.com> <michaelv.760723129@ponderous.cc.iastate.edu> Date: Thu, 10 Feb 1994 22:31:26 GMT In article <michaelv.760723129@ponderous.cc.iastate.edu> michaelv@iastate.edu (Michael L. VanLoon) writes: >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). If you unprefix ^S and download a binary that contains a ^S, >>the serial port hangs consistently. This bug still exists in >>NetBSD-current as of 1/24/94. >>-- >>Mike Long Mike.Long@Analog.com > >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). SET FLOW RTS/CTS in Kermit should shut XON/XOFF flow control off; it works on other Un*ces, why not NetBSD? Also, regardless of the XON/XOFF flow control setting, the com driver should never get itself into a state such that it can't be closed. The fact that SIGTERM can't kill the process means that signals are not being processed, which means that the process must be hanging in kernel-land (= COM DRIVER). -- Mike Long Mike.Long@Analog.com VLSI Design Engineer voice: (617)461-4030 Analog Devices, SPD Div. FAX: (617)461-3010 Norwood, MA 02062 *this = !opinion(Analog);