> From: osymh@gemini.oscs.montana.edu (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).

Thanks,
-SR