dave@lsuc.UUCP (David Sherman) (12/30/84)
Almost all of the terminals on our UNIX system are VT-100-compatible
Esprit terminals. They have a NO SCROLL key which transmits ctrl-S
and stops terminal output locally. The terminal will only restart on
receipt of a ctrl-Q.
If you press the NO SCROLL key (which, incidentally, is easy to do
by accident on these terminals), UNIX will see the ctrl-S and stop;
but then _any_ key will let UNIX restart, not just ctrl-Q. This means
data can be lost, if you press NO SCROLL, any other key, and then
wait a bit before ctrl-Q -- UNIX starts resending, but the terminal
won't display it until it gets the ctrl-Q (or you press NO SCROLL again).
I'd like to change UNIX to require ctrl-Q (actually t_startc)
to restart output. With our terminals, it can only improve things -
as it is, users have to know to press the NO SCROLL again (or hit
ctrl-Q explicitly). Is this likely to cause any problems anywhere
else?
We're running v7 on a Perkin-Elmer 3220, by the way. The change is
trivial - commenting out two lines in /usr/sys/dev/tty.c.
As an alternative, I'm thinking of creating a new ioctl setting
(TIOCQSTART?) which controls this behaviour, so it's user-settable.
Any comments on that idea?
Dave Sherman
The Law Society of Upper Canada
Toronto
--
{utzoo pesnta nrcaero utcs}!lsuc!dave
{allegra decvax ihnp4 linus}!utcsrgv!lsuc!daverpw3@redwood.UUCP (Rob Warnock) (01/01/85)
+--------------- | I'd like to change UNIX to require ctrl-Q (actually t_startc) | to restart output. With our terminals, it can only improve things - | ... Is this likely to cause any problems anywhere else? | | We're running v7 on a Perkin-Elmer 3220, by the way. The change is | trivial - commenting out two lines in /usr/sys/dev/tty.c. | As an alternative, I'm thinking of creating a new ioctl setting | (TIOCQSTART?) which controls this behaviour, so it's user-settable. | Any comments on that idea? | | Dave Sherman | The Law Society of Upper Canada | Toronto +--------------- The 4.1bsd (and 4.2bsd too?) has a tty mode set by "stty decctlq" which, as it says in "stty(1)", means: decctlq After output is suspended (normally by ^S), only a start character (normally ^Q) will restart it. This is compatible with DEC's vendor supplied systems. Likewise: -decctlq Atfer output is suspended, any character typed will restart it; the start character will restart output without providing any input. (This is the default.) At Fortune Systems (which used a v.7-based kernel), the "decctlq" feature was needed (and added to the kernel, along with most of the 4.1 tty stuff) to solve problems similar to yours with overrunning terminals which were taking a long time to perform complex area fills. The user had no way of knowing the output was turned off, but was just holding down a cursor motion key (on auto-repeat), causing the driver to start output too soon after the terminal had shut it off! (Also, the cursor was a 3-char sequence, and the driver was eating one or the other of the chars when restarting output.) So, yes. It is a needed feature. The only thing you want to make sure of is that even if output is stopped, the interrupt and quit functions must turn it back on (when the terminal is not in "raw" mode). Otherwise, you can confuse and frustrate the user, who hit XOFF to stop the action, and now can't get his/her shell back! (Breaking the <DEL> key... <DEL> <DEL> <DEL>...) An XON gets a string of prompts which have been stacked up, leading to more confusion. (Certain versions had that problem, and it hurt.) I suspect that if you merely "comment out the two lines" you will create the bug. Be careful. (Get 4.1 sources, if your license permits.) Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (01/02/85)
> I'd like to change UNIX to require ctrl-Q (actually t_startc) > to restart output. With our terminals, it can only improve things - > as it is, users have to know to press the NO SCROLL again (or hit > ctrl-Q explicitly). Is this likely to cause any problems anywhere > else? > > We're running v7 on a Perkin-Elmer 3220, by the way. The change is > trivial - commenting out two lines in /usr/sys/dev/tty.c. > > As an alternative, I'm thinking of creating a new ioctl setting > (TIOCQSTART?) which controls this behaviour, so it's user-settable. Instead of making yet another incompatible flavor of UNIX, how about implementing either the 4.?BSD "new tty" handler or the UNIX System ? tty handler. Both of these have fairly general control over STALL and RESUME characters.
BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa> (01/02/85)
Ahh, reaching into that frightening piece of wisdom and arcanum the 4.2bsd TTY(4) manual (many) page(s) we find the local mode LDECCTQ 'Only ^Q restarts output after ^S, like DEC systems' so it looks like you are in fine company. Maybe you should call it LPERKKTQ? -Barry Shein, Boston University
qwerty@drutx.UUCP (Brian Jones) (01/02/85)
stty -ixany should also cause the dc1/dc3 sequence to be recognized
exclusively. It is a lot easier than patching source
code.henry@utzoo.UUCP (Henry Spencer) (01/02/85)
Strictly speaking, ctrl-Q should be the only thing that restarts output.
The fundamental problem is that flow-control protocols really ought to
be implemented so that they are invisible to higher levels, notably to
the user, and XON/XOFF isn't. So we have a fundamental confusion about
whether the terminal is invoking flow control to slow down (not stop)
the flow of data, or whether the user is invoking the same machinery to
stop output for some potentially-unbounded period. The decision about
restart characters depends on which of these cases is occurring. If the
user is stopping output, restarting it on any input character is a much
more "idiot-proof" approach. Ctrl-Q is not exactly an obvious combination
for a user who is wondering why in $^%$^% his terminal won't respond. It's
not too bad if he stopped output deliberately, but if he hit ctrl-S quite
by accident...! On the other hand, if the terminal knows about the flow-
control protocol and is using it deliberately, then violations of it are
fraught with potential problems, as you're discovering.
There is no entirely satisfactory solution. Given that the violation of
the protocol is fouling up the terminals, your best solution is probably
to make the change and live with the occasional "my terminal is hung"
phone calls that will result.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henryguy@rlgvax.UUCP (Guy Harris) (01/03/85)
> The only thing you want to make sure of is that even if output is stopped, > the interrupt and quit functions must turn it back on (when the terminal > is not in "raw" mode). Well, err, umm... System III did this, but System V doesn't, and 4.xBSD never did. I don't know about TOPS-[12]0 or VMS or any DEC operating systems. I suspect they don't, because it gives VT100s the ****fits. The VT100 has a very small buffer between the comm line and the screen updating code, so it demands *very* strict XON/XOFF flow control, especially in smooth-scroll mode. I have seen a fair amount of output get scrambled by hitting the interrupt key in the middle of output; it stopped happening when we had interrupt and quit not affect the flow control state. (UNIX can cause XON/XOFF problems even when working correctly; its habit of surrounding every critical region with spl5() (or whatever) and running all interrupt service routines at interrupt priority all the time means it doesn't always respond to an XOFF in time.) Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (01/03/85)
Whether interrupt should unstall output depends on whether one views DC3/DC1 flow control as user-controlled or as hardware- controlled. It is more important to get the hardware working right, to avoid hung terminals (e.g. VT100 with VT640 graphics, Teletype 5620). Most fancy terminals that perform DC3/DC1 flow control also coordinate this with user scroll control via ^S/^Q or a scroll/no-scroll key. There are UNIX terminal drivers that will continue dumping a lot of characters to a terminal that has tried to stall by sending a DC3. The worst offenders are probably those that insist on using input silo level alarms. Such terminal drivers are broken and should be fixed. (This is possible, since there are also UNIX terminal drivers that do this right.) If your users can't be taught that interrupt doesn't automatically unstall their terminal, then you have other worse problems to worry about! Try taping "TYPE CTRL-Q" notes on their terminals.
guy@rlgvax.UUCP (Guy Harris) (01/04/85)
From the original article: > I'd like to change UNIX to require ctrl-Q (actually t_startc) > to restart output. ... > We're running v7 on a Perkin-Elmer 3220, by the way. The reply: > stty -ixany should also cause the dc1/dc3 sequence to be recognized > exclusively. It is a lot easier than patching source > code. *Ahem.* This is the case with the System N driver, for N >= III. The driver was much changed in System III; the "IXANY" bit was not in any other UNIX terminal driver. Specifically, it is not in the V7 driver. Berkeley's "V7 with goat gland injections" driver has a bit which is the inverse of this, called LDECCTQ. As such, "stty -ixany" doesn't do a bit of good to a user running V7 on a Perkin-Elmer 3220, and patching source code *is* required to make XON/XOFF handling strict on that system. Please don't assume that everybody is running your version of UNIX. Also, if you *are* asking a question about UNIX, please state the derivation of the version; it will help people to give you an answer pertinent to that version. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
guy@rlgvax.UUCP (Guy Harris) (01/04/85)
> Whether interrupt should unstall output depends on whether one > views DC3/DC1 flow control as user-controlled or as hardware- > controlled. It is more important to get the hardware working > right, to avoid hung terminals... Bravo! (Although Bravo probably didn't have this problem, since if the CPU can push the bit map directly there's no worry about flow control... :-)) VT100s are notorious for requiring *very* strict XON/XOFF handling, especially in smooth scroll mode. > There are UNIX terminal drivers that will continue dumping a lot > of characters to a terminal that has tried to stall by sending a > DC3. The worst offenders are probably those that insist on using > input silo level alarms. Such terminal drivers are broken and > should be fixed. (This is possible, since there are also UNIX > terminal drivers that do this right.) To be precise, the V7 DH11 driver adaptively set the silo alarm level based on how full the silo was when it was last drained. That code pretty much dropped in to the 4.1cBSD DH and DZ drivers. (I remember reading that the RSX-11D/IAS DH and DZ drivers also set the silo alarm level adaptively.) We found that it didn't clear up all the occasional glitches we saw, however; we later profiled the system using the System III/System V kernel profiler (which doesn't do a graph profile like the 4.2BSD profiler but which is claimed to consume little overhead, can be turned on and off on a production system, and drops into the 4.2 kernel with little work) modified only to profile routines running with an interrupt level greater than spl5() level, and found that the system was spending quite a bit of time in interrupt service routines *et al* at elevated priority (if I remember correctly, the disk driver "hp.c" was one of the major culprits) - enough time to delay the interrupt that tells the host that an XOFF came in until after it was too late. The DEC operating systems keep the time spent at elevated priority within ISRs as low as possible; this improves real-time response, and could be applied to UNIX. (Does anybody know if any of the DEC OSes have XON/XOFF trouble with smooth-scrolling VT100s at high baud rates? We saw the most trouble at 19200 baud, which is not supported by a standard DH and is not supported by all DZs either.) > If your users can't be taught that interrupt doesn't automatically > unstall their terminal, then you have other worse problems to > worry about! Try taping "TYPE CTRL-Q" notes on their terminals. DEC's word processors were built out of VT52s, and later VT100s, and PDP-8s; I remember one of their manuals telling the user that if the system doesn't seem to be responding to their typing, they should hold down the button labelled CTRL and typing the Q key... (Which was one reason I insisted that the custom firmware in the terminals we offer with our office automation systems could be put in a mode which prevented the user from typing control keys.) Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
dave@lsuc.UUCP (David Sherman) (01/08/85)
In article <104@redwood.UUCP> rpw3@redwood.UUCP (Rob Warnock) writes: || The only thing you want to make sure of || is that even if output is stopped, the interrupt and quit functions must || turn it back on (when the terminal is not in "raw" mode). Otherwise, you || can confuse and frustrate the user, who hit XOFF to stop the action, and now || can't get his/her shell back! (Breaking the <DEL> key... <DEL> <DEL>...) || An XON gets a string of prompts which have been stacked up, leading to || more confusion. (Certain versions had that problem, and it hurt.) Turning output back on isn't enough, though. With these terminals, if you've hit the NO SCROL key, and then you hit DEL to interrupt, if UNIX turns on the text again you still won't see anything until you press NO SCROL again. Dave Sherman The Law Society of Upper Canada -- {utzoo pesnta nrcaero utcs}!lsuc!dave {allegra decvax ihnp4 linus}!utcsrgv!lsuc!dave
jerry@oliveb.UUCP (Jerry Aguirre) (01/19/85)
I have made a modification to our system to do this. We run mostly
vt100s and the interference of type ahead with the vt100's Xon/Xoff can
be annoying.
The problem can occur when the user types during high baud rate
output. For example cat a large file and while it is outputing type in
the next command. The screen will contain blocks which are the vt100's
way of telling you that it's input buffer overflowed. It can be hard
to duplicate this as system load may slow the output and some vt100s
have larger input buffers than others. It is easy to exaggerate the
problem though. Just cat a large file, quickly type control-S, type a
space, wait a few seconds, then type control-Q. The resulting output
will be truncated because Unix restarted the output after the space and
the vt100's input buffer overflowed.
I modified the Berkeley "tset" command to examine the terminals termcap
for a ":QS:" entry. This fits in with tset's use of other capital
termcap entries for setting delays and such. If the QS entry is there
it does the appropriate ioctl to set "restart on control-Q only".
Fortunately all our systems had the appropriate ioctl to do this. I
suggest you look hard before modifying your kernel. The ioctl may be
there but just hard to find. Check the tty(4) man page carefully.
I like the tset approach as it makes the change terminal dependent.
Terminals without built-in flow control still have the benefit of the
restart on any character "feature". Also, as has been mentioned
before, this change does not destroy the restart on any character
feature. The user of a vt100 never had that feature. Even when Unix
sent the characters, the vt100 refused to display them!
I can post the diffs to tset but as has been mentioned the ioctl
required is very system dependent. I have the changes for the BSD 2.8,
2.9, and 4.1 systems. Even within BSD all three are different.
Jerry Aguirre @ Olivetti ATC
{hplabs|fortune|idi|ihnp4|tolerant|allegra|tymix}!oliveb!jerrygwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (01/21/85)
> I modified the Berkeley "tset" command to examine the terminals termcap > for a ":QS:" entry. Please don't do this. The termcap Boolean capability "xo" already indicates that the terminal requires DC3/DC1 (XOFF/XON, ^S/^Q) flow control. Use this instead of inventing another. Thanks.