On Mon, Jun 18, 2001 at 03:54:41PM -0400, Greg A. Woods wrote:

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

I tried using rtscts hardware flow control, but it's not totally clear
to me that the terminal supports it. It didn't give errors, but it seems
that either shells turn this off, or the setting has no effect.

> 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.  

I think so. Going to 9600bps does reduced the problem a lot, except
on the more complex shell prompts. I tried inserting some small 3-5ms
delays in the termcap entry for newlines and carriage returns, but it
seems to have no effect.

It might be you could leave the shell's stty code alone and just
introduce delays, but I'm not yet convinced that would help.

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

Some terminals and other serial hardware just barely meet their specs,
giving little margin for variations in operation. 

> 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).

I would like to have a terminal that could handle 38400. This thing cost
me $25 7 year ago. Cost of ownership is pretty good so far... :)

> 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.

This works fine. I have even wondered if this is a problem specific to
NetBSD-sparc, or just the sparc hardware. Maybe toying with stty setup
is OK on other hardware, or maybe it triggers an as yet unknown race
condition or similar problem somewhere.

> 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:

The ? from an xterm might be an unprintable too, like the digraphs I see
on my DEC. Nice to see you can reproduce this. 

> 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)

I don't see this myself, but it would also be caused by network/xterm
interaction. I say that because I _have_ noticed that when using
terminal servers before. Just a thought.

> 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.

Matches what I see. I don't quite understand why a shell would do
something like that though. Also, if the tty driver needs to do flow
control, I would think it would handle that the right way irregardless
of what the user level program did.

> 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.

I might peek at the shell sources; it's just a lot of code to digest.
Hopefully one of them is reasonably modular, and the tty calls are
well isolated.

-- 
 "There are nowadays professors of philosophy, but not               | | |
 philosophers."                                                      | | |
________________________________________________________________    /  |  \
s h a n n o n @ w i d o m a k e r . c o m                         _/   |   \_