nckary@ndsuvax.UUCP (Dan Kary) (09/05/85)
We are having some trouble with long (250') terminal lines. When the system is booted the login message is sent out each line. If the terminal on one of these long lines is turned off, there is an echo on the line that is interp- reted as a login name. After 60 seconds login times out and sends a new login message causing the sequence to repeat. Considerable CPU time can be wasted if several lines are doing this at one time. This is a serious problem for us because our machine shuts down each night to do backups, file consistency and quota checks. The noisey line problem occurs each morning when the machine reboots. The machine is a VAX 11/780 running 4.2BSD. The serial line controllers are DEC DMF32's. I suspect that other sites have seen this problem. What options do we have for preventing this problem (other than not rebooting every night)? Dan Kary North Dakota State University 300 Minard Hall Fargo, ND 58105 (701) 237-8171 ihnp4!dicomed!ndsuvax!nckary
phil@amdcad.UUCP (Phil Ngai) (09/09/85)
This doesn't really belong in net.bugs.4bsd but there are two things you
can do. One is to make getty ignore its input for a couple of seconds
after it sends out its banner and then flush input. This will have the
side-effect of screwing your users who type quickly but they will learn
to wait before trying to type their name.
The second one is more drastic and is needed if you run two or more terminals
over a single cable, such as inside telephone 25 pair cable and some of
the lines are left open or connected to turned off terminals. This is
a hardware hack. What you need to do is pull the computer's receive line
far enough below its logic threshold that crosstalk from the adjacent
lines will not be seen as input. If you can find the right voltage on the
DMF, then you just need a (perhaps 10K) resistor per tty port. If you don't
have access to anything (our situation) you can fake it with a diode, a
resistor, and a cap. Connect the cathode of the diode to the computer's
transmit line. Connect the anode to a .1uF cap. Connect a 10K resistor
between the cap and the receive line of the computer.
This is a gross and ugly kludge but it does work. The diode and cap
implement a -12V source for the pulldown resistor without loading the
transmit line in a noticeable way.
Hope one of these works for you.
--
A hacker is someone who orders Sweet and Sour Bitter Melon just because
it is "an impossible combination".
Phil Ngai (408) 749-5720
UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil
ARPA: amdcad!phil@decwrl.ARPAjohn@frog.UUCP (John Woods) (09/09/85)
>We are having some trouble with long (250') terminal lines. When the system >is booted the login message is sent out each line. If the terminal on one of >these long lines is turned off, there is an echo on the line that is interp- >reted as a login name. After 60 seconds login times out and sends a new login >message causing the sequence to repeat. Considerable CPU time can be wasted >if several lines are doing this at one time. > ihnp4!dicomed!ndsuvax!nckary > A "fix" to a similar problem that we have at mitccc is the following: login (or rather, getty) has an optional flag which tells it to: wait 3 seconds after issuing a prompt, flush input, and then do the read for the login name. Not terribly elegant, at times slightly annoying, but it does solve the problem. -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc@MIT-XX.ARPA "Out of my way, I'm a scientist!" - War of the Worlds
jerry@oliveb.UUCP (Jerry Aguirre) (09/24/85)
> We are having some trouble with long (250') terminal lines. When the system > is booted the login message is sent out each line. If the terminal on one of > these long lines is turned off, there is an echo on the line that is interp- > reted as a login name. After 60 seconds login times out and sends a new login > message causing the sequence to repeat. Considerable CPU time can be wasted > if several lines are doing this at one time. > Dan Kary > North Dakota State University With all the responses about time delays and pull-down resistors I am supprised that no one offered the most obvious sollution. Connect the modem control signals. 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. It only takes one more wire to implement this most basic of controls and there are several benifits. - The init will hang on open to a line without DSR. 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. - When a user powers off his terminal at the end of the day then he is automatically logged out. Also handy when you hang your port and need to restart from login. Three second timeouts! Pull down resistors! Comon people, get real. Jerry Aguirre @ Olivetti ATC {hplabs|fortune|idi|ihnp4|tolerant|allegra|tymix|olhqma}!oliveb!jerry
nckary@ndsuvax.UUCP (Dan Kary) (09/30/85)
> With all the responses about time delays and pull-down resistors I am > supprised that no one offered the most obvious sollution. Connect the > modem control signals. > Jerry Aguirre @ Olivetti ATC > {hplabs|fortune|idi|ihnp4|tolerant|allegra|tymix|olhqma}!oliveb!jerry We are unable to use the modem control lines because we are using DEC DMF32 serial line controllers. Each controller has 8 async lines, 1 sync line and parallel input and output ports. The modem control lines are brought out to the distribution panel only for lines 0 and 1. Lines 2 thru 7 have only TXD, RXD and Gnd. I think I mentioned that in the original article, which was posted to net.dcom. The symptom has been cured by adding a 1 second delay in getty after printing the login message, followed by flushing the input. Many thanks to all responders. Dan Kary North Dakota State University ihnp4!dicomed!nckary
emrath@uiucdcsb.CS.UIUC.EDU (09/30/85)
(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@uiuc.edu) Center for Supercomputing Research and Development University of Illinois
phil@amdcad.UUCP (Phil Ngai) (10/03/85)
In article <604@oliveb.UUCP> jerry@oliveb.UUCP (Jerry Aguirre) writes: >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. We found that in our environment, where people had switch boxes to select between their Unix port and a CP/M system, noise would couple onto the DSR lines just like it coupled onto the computer's RxD line. This had the effect of someone calling up a dialup modem and hanging up, over and over. The getty spawning made the computer run slowly. I suppose if your users didn't effectively disconnect the terminal line on a daily basis, using DSR might work. Or if your environment were less noisy than ours. -- Arthur Rudolph believed that technology is morally neutral and so, therefore, are those who create it. Phil Ngai +1 408 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.ARPA