Subject: Re: Serial port flowcontrol problems
To: None <firstname.lastname@example.org>
From: Stephen J. Roznowski <email@example.com>
Date: 10/13/1994 21:59:14
> From: firstname.lastname@example.org (Michael L. Hitch)
> On Oct 13, 12:32am, "Stephen J. Roznowski" wrote:
> > I'm running an A3000 with a kernel built from the 941011 sup.
> > When I connect to a remote system using the 189 version of kermit at
> > 38400 and cause a lot output to be generated (for example, by executing
> > lptest), my modem locks up. Redoing the same test at 19200 seems to
> > work. Just before the session locks up I get a lot of ^Gs printed.
> > Has anyone else see this?
> I have had this problem before. I was using kermit and connected to a
> remote system through a DEC terminal server. If I connected to an
> Ultrix system and did a large amount of output (i.e. more than 1 screen
> full), my Ultrix session would lock up. I could send a break and get
> back to the the terminal server, but my session to Ultrix was hung. At
> times, I would see a number of ^G characters also. If I connected to a
> VMS system and did some output, I would get some kind of I/O error.
> I think there is a problem in kermit that doesn't set crtscts on the
> serial line, even if you tell kermit to do rts/cts flow control. When
> the NetBSD tty input handler gets a lot of input and the input buffer is
> close to filling up, it will try to stop the input. If crtscts isn't
> set, it will send X-OFF. The buffering of data in the serial input
> interrupt (up to 512 characters) will still allow a number of characters
> to be still be passed to the tty input, which could overflow the tty
> input buffer. If the tty buffer fills up, the tty input routine echoes
> a bell (^G) for each character received.
> To further aggravate the problem, if the modem is configured for rts/cts
> flow control, the X-OFF sent by the tty input routine will be sent to the
> remote system. In this case, there is very likely to be quite a bit of
> data buffered in the modems, which will also cause the tty input buffer
> to overflow.
> I think I was able to force the serial line to crtscts by either
> setting it prior to entering kermit, or executing an stty command after
> kermit set the line.
> I think I also saw a patch to kermit to fix setting crtscts on the
> serial port. There is also a newer version of kermit available, which I
> think does set crtscts properly. The kermit I'm running now sets
> crtscts properly, and I had much less trouble with this type of problem.
Well, this helped to fix the problem... If I do a "stty crtscts" on
both ends, I'm able to run at 38400 (yea!). I'm also running kermit(190)
now, but it didn't appear to set this automatically (it might be a new
option that I haven't found (yet) though).