[ On Monday, June 18, 2001 at 01:57:33 (-0400), Shannon Hendrix wrote: ]
> Subject: Re: DEC vt320 terminal problem
>
> ksh seems to have as much trouble as the rest.  If I hold down ^J and
> let it autorepeat, I'll see the occasional >= digraph I mentioned
> earlier.
> 
> Doing the same thing in any other program works fine.

Ah Ha!  Now I think we're getting to the bottom of the problem.

> The vt320 terminal uses an 8051 microprocessor as far as I know, and I
> do have to use handshaking or it will lose data on fast outputs. It's
> not the fastest terminal in the world, even though it's clocked at
> 16MHz.
> 
> But since this is still shell only, I was wondering if something is
> happening, only in a shell prompt, that is causing a timing issue? Not
> trying to confuse things, but it's a thought.

I think there may be some inadvertent interaction with flow control and
the shell continually switching the tty setting.

A silly hack that might eliminate at least this particular manifestation
of the problem would be to fix the shell not to automatically change the
tty settings unless it's about to fork another process.  This way
leaning on the return key to get a stream of prompt lines wouldn't
continually twiddle the tty driver and whatever flow control mechanism
is in use would be unaffected and would hopefully be able to continue
working just fine.

> I have the same trouble at 9600bps BTW, so I don't think it's a simple case of
> buffer overruns or some such.

My VT100 (which has an 8080 CPU, at 2MHz IIRC) cannot sustaining 9600bps
with short output lines and lots of scrolling either.

I seem to remember having similar problems with that same VT100 when I
tried to use it on my Sun-3 as the console, and with pdksh as my shell,
but running SunOS-4.1.1u1.  I knew it was a flow control issue, though
instead of figuring out where exactly the problem was I just switched to
a faster terminal I happened to have available (an AT&T-605).

> Again using display instead of interpret controls, I get a stream of
> <cr><cr><lf> characters from ksh with a simple $ prompt, with the
> occasional <cr><cr>u' instead.
> 
> The u' digraph is coming in place of the linefeed, which sounds like
> timing to me.  The simple prompt just causes this to happen much
> less often, or at least that's what it looks like.

Yes, I think that's it almost exactly.  Final confirmation might come
from one more test.  Try doing that same test with /bin/sh and without
any editing modes enabled.  I think in this case sh will leave the tty
settings alone and there should be no adverse interaction with flow
control.

Hmmm.....  it seems I can even reproduce this problem or something very
similar with my console server with the sparc-20's console using an
xterm running telnet to connect to the port; if I make my prompt long
enough (even 40 or so characters is enough).  I simply lean on the ^J
key and occasionally I get strange things like a "ó" that's apparently
entered on the command line because ksh spits back:

	ksh: ó: not found

The funny character is usually different with each occurance, but it's
always had the high bit set in my few short tests.

If I switch to /bin/sh then the problem goes away and no characters are
ever dropped or inserted.  (there is a funny visual artifact though
because the shell doesn't actually print a newline after the prompt --
it's the tty driver that echos the typed newline, so when flow control
happens then the prompts all bunch up together on one line, but I
remember this happening on every Unix all the way back to V7)

If I then simply turn command-line editing on in /bin/sh (set -o emacs)
then the problem immediately re-appears exactly as it did in /bin/ksh.

So, it does indeed seem that something bad happens in conjunction with
flow control when the shell diddles the tty settings on every prompt.
Perhaps the tty driver is unable to do flow-control properly while it's
processing the stty ioctl() call.  In my case it seems to be
transforming the input <^J> into some high-bit character -- perhaps by
causing the UART to drop one or two bits from the incoming data stream
and thus effectively joining two of them back to back or some such.

Given the little bit I do know of UARTs and TTY drivers I don't know if
there's any better fix than to simply fix the various shells as I
described above.

The upshot though is that the problem should not manifest itself so long
as the program you're using doesn't frequently diddle the tty settings
while sending largish amounts of output to a terminal that might need to
use flow control to keep up.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>