das@cirl.UUCP (Dave Steffens) (08/16/86)
This is part two of a two-part posting.
*** What you should know about using BREAK for modem speed switching.
I'm really not in the business of providing software support for DEC Ultrix.
But since I seem to be one of the few Ultrix system administators on the net
with some experience to share, here goes. Ultrix administrators tune in.
Others should probably hit the "n" key now -- this is a LONG posting.
However, the following info does apply to unix systems other than Ultrix.
I will try to respond to email and phone calls (after 1400h EDT please).
Apologies in advance to anyone who might deem this posting inappropriate.
DISCLAIMER: The following was my experience with Ultrix 1.1 and may NOT be
wholly applicable to Ultrix 1.2 with which I have NO direct experience.
The following is a copy of a note I published on the net a few months ago
and a copy of some email I sent in reply to a request for more info.
You will need source to implement this fix. If you have no source but are
running Ultrix 1.1, I can send you a uuencoded binary of our /etc/getty.
If you are running Ultrix 1.2 you are out of luck because I understand that
/etc/getty has been modified significantly. Perhaps you can get someone on
the net with 1.2 source to make this change and send you a uuencoded binary.
----------
Subject: getty mod for bouncy BREAK keys
Index: src/etc/getty/main.c
Description:
We recently installed 2400/1200/300 baud modems on a VAX750
with MDB DZ's and Able VMF32's running plain vanilla 4.2bsd
and on a uVAX II with DHV's running Ultrix 1.1. We created
a 1200/2400/300 baud rotary table entry in /etc/gettytab which
starts the dialup off at 1200 baud. Well, everything is hunk-dory
on the 750, but on the uVAX it proved near impossible to get
to 2400 baud. It seemed that /etc/getty was seeing multiple BREAKs
(most of our terminals have un-debounced BREAK keys) and making
several trips around the rotary, usually stopping at 300 baud.
We never figured out why the problem appeared only on the uVAX.
Speculation has it that the uVAX is "just plain faster" so it sees
the multiple BREAKs whereas the 750 doesn't, but it could be that
the DHV handles framing errors differently than the DZ and VMF32.
Fix:
Install a sleep(2) in getty/main.c as shown below. I've tried
to include enough context to show where the sleep(2) goes and how
it fits into the program flow, hopefully without giving away any
state secrets :-). The +'s at the left margin show what I've added.
The source I used to cobble this up is from 4.2bsd.
main(argc, argv)
char *argv[];
{
...
for (;;) {
...
if (getname()) {
...
}
alarm(0);
signal(SIGALRM, SIG_DFL);
signal(SIGINT, SIG_IGN);
+ /*
+ * A zero return value from the call to getname()
+ * probably means that the BREAK key was pushed.
+ * Wait a few seconds to give the line time to settle down.
+ * This is necessary for those terminals like the H19
+ * which do not debounce their BREAK keys, DAS MAY-86
+ */
+ sleep(2);
if (NX && *NX)
tname = NX;
}
}
----------
Subject: Re: getty mod for bouncy BREAK keys
Thanks for your reply. Sorry I wasn't clear about how our terminals generate
BREAK and what happens at the computer interface. Let me try once again.
All switches "bounce" for several tens of mSec after opening or closing.
On most keyboard keys this causes no problem because it is supressed
by the terminal logic that transforms key pushes into EIA signal levels.
When you do get multiple chars from a single key push, it is usually because
the key switch has gotten so noisy that it bounces longer than the dead time
built into the logic -- it begins to look as if the key was pushed twice.
While EIA specs say that a **true** BREAK should be exactly 1/4 Sec of space,
I have found that many inexpensive terminals do NOT adhere to this standard.
There is NO timing of the BREAK character -- the terminal causes the line to
space as long as you hold down the BREAK key. When the BREAK key is released,
it "bounces" just like all the other keys. But because there is no logic
on the BREAK key to suppress these bounces, they appear on the line as a series
of 2-10 mSec spaces separated by 2-10 mSec marks. Typically there will be
5-10 of these space/mark "glitches", with the first ones having longer space
than mark times and the later ones having longer mark than space times.
Now most computer interfaces detect BREAK as a framing error, i.e. a space
where the stop bit should be. Since a character at 2400 baud is about 4 mSec,
ANY glitch longer than 4 mSec will generate a framing error, i.e. will appear
to /etc/getty just like a REAL 1/4 Sec "BREAK". Similarly, ANY glitch
shorter than 4 mSec will appear to /etc/getty as a REAL character.
Since the first few space/mark pairs usually have the longest space times,
what /etc/getty ultimately sees is something like:
BREAK BREAK BREAK garbage-char garbage-char
So this is what I meant when I said our terminal BREAK keys send "several
BREAKs followed by a few garbage characters" -- that's how the line glitches
look to /etc/getty after the serial line interface has processed them.
Our terminals work the same way at all baud rates. But since the character
time is 8 mSec at 1200 baud and most of the glitches are shorter than this,
most will appear as garbage chars at 1200 baud and few, if any, as BREAK.
/etc/getty seems better equipped to handle garbage chars than multiple BREAKs
so this may be why there is more of a problem at 2400 baud than at 1200 baud.
Note that this problem was seen frequently on a uVAX with DEC DHU boards
but only rarely on a VAX750 with DEC DZ and Able VMF32 boards. It was never
seen on an 11/34 with MDB DZ boards. So there still may be some unexplained
differences in how each type of terminal interface handles framing errors.
--
{harvard,mit-eddie,think}!eplunix!earvax!das David Allan Steffens
243 Charles St., Boston, MA 02114 Eaton-Peabody Laboratory
(617) 523-7900 x2748 Mass. Eye & Ear Infirmary