Login Problem (250' RS-232 Lines)

[emrath at uiucdcsb.CS.UIUC.EDU]

(Sorry 'bout the length of this mess)
There are a number of problems with Jerry's response with respect
to the long line problems we're having here.  More about those
problems and solutions later.

>> If you connect the Data Terminal Ready (DTR) of the terminal to the Data
>> Set Ready (DSR) of the computer port, then the getty will not send login
>> messages to terminals that are turned off.  Nor will it listen to
>> garbage on the line.

Correction: unix uses the Carrier Detect (CF) signal,
not the Data Set Ready (CC) signal.
The carrier detect line has the same kind of termination that the
received data line has.  Why would that wire be immune to noise?
Methinks I'll just be wasting cycles firing up gettys and HUPing them
instead of processing noise characters.

>> It only takes one more wire to implement this most basic of controls and
>> there are several benifits.

We have two-twisted-pair shielded cables (the usual Belden 8723) strung
throughout the lab.  Since we are running many cables up to 450 feet
at 19200 baud (and getting away with it!), we need a solid ground on
one wire of each pair.  We have no spare conductors and can't afford to
rewire.

>> The init will hang on open to a line without DSR (sic).  Not only
>> does this save an exec of getty for unconnected lines, but it
>> becomes possible to distinguish from the ps display whether
>> there is a terminal connected to that line.

Saving an exec of getty buys you nothing.  Init has already done the
fork and allocated a process for the tty.  We find it annoying that
the TT slot in a ps display shows ? for these inits instead of the
tty that they are waiting on.

>> When a user powers off his terminal at the end of the day then
>> he is automatically logged out. 

Many users have learned that sometimes a terminal is too intelligent
for its own good and gets real confused because of some erroneous
control char sequence.  They've also learned that the easiest cure is
to toggle the power.  They would not appreciate being logged out.
I know of others who power down when they leave and would complain
loudly at being logged out.

----------------------------
Now on to our problems and what we've found and done.

Our first thing was to put in the delay after the banner, but since
I myself am one of those faster typers who doesn't like that 1 or more
second delay, I went in and changed getty so that the pf# gettycap
was in milliseconds instead of seconds, and set it to 50.
Helped immensely and is not a noticeable delay.
But for us, that is not enough.  The long lines sometimes generate
a continuous stream of noise, many of which are DELs and cause
INTR signals (getty is really flakey in its handling of the
tty and it is continually bouncing into cooked mode).
It turns out to really suck down the cycles.
I believe that resistors or some fancier biasing network would solve
the problem, and would probably increase the bandwidth of the lines
since it would decrease the impedance and hence the time constant.
But when facing 128 mux ports, a software fix is much more attractive.

If you get to thinking about it, even if you get getty to ignore the
noise characters coming in, you still have the device driver servicing
all those interrupts.  We have done massive codectomies in getty and
have set it up to recognize and count the noise.  After getting enough
of it, getty completely closes the tty, sleeps for a while (60 seconds),
and then exits, allowing a restart.  It was necessary to modify our dmf
driver to completely disable the line in dmfclose, since this wasn't
being done and the driver would've continued servicing interrupts.
We put lots of debug logging info into getty to demonstrate the effects
of the changes.  Between that and ps displays, I believe we *finally*
have the problem under control.

While thinking about this fix, I got to wondering about race conditions
between open and close.  Turns out that they aren't synchronized.
I came up with a test program that demonstrates this beautifully.
If an open occurs while ttyclose is waiting for output, it doesn't
work and the opened file returns I/O errors.  If close disables the
line, an overlapping open results in the tty getting hung.
We believe the fix is that the inode should be locked (it isn't) while
a character device is being called to do an open or a close, but I
haven't found the time to work on that.

Also, there was a bug in that dmfclose dropped DTR without waiting if
HUPCLS was set and DISC==OTTYDISC.  Depending on your connection,
this causes carrier to drop, which flushes the output queue.
It's fixed by putting a ttywait(tp); before the HUPCLS test in dmfclose.


	Perry Emrath	(emrath at uiuc.edu)
	Center for Supercomputing Research and Development
	University of Illinois