Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!houxm!mtuxo!mtune!codas!akgua!emory!km
From: km@emory.UUCP
Newsgroups: comp.unix.wizards
Subject: DTR Problems
Message-ID: <1995@emory.UUCP>
Date: Wed, 25-Feb-87 11:16:36 EST
Article-I.D.: emory.1995
Posted: Wed Feb 25 11:16:36 1987
Date-Received: Sat, 28-Feb-87 05:31:31 EST
Organization: Math & Computer Science, Emory University, Atlanta
Lines: 32
Keywords: DTR getty dh dz cs11 cs21

We have been having the following problem on 4.3BSD (acutally
the Mt Xinu release, though I doubt it is related to their
NFS mods).

Getty does not always raise DTR on its port. Mostly it does
but occassionaly it does not. If we kill a getty that is not
raising DTR, it generally is replaced by one that does. We
don't know if the "bad" getty never raises DTR or if it just
drops it after a while (while waiting a long time for DCD).

Our ports are connected to a variety of modems and port selectors
that depend on seeing DTR on the port before they will talk to
it. The net effect is that over a period of days the number
of bad ports grows, until there are not enough live ports
available. At that point we either reboot or kill the bad
getty's en masse.

We see the same problem on Vax 780s and 750s. We run both the
dh and dz drivers, on DEC dzs and Emulex CS11 and CS21s. The
equipment connected to it is a variety of port selectors
and modems from Applitek, Micom, Hayes, Dec, and others. The
problem seems to be independent of the combination of hardware.

I suspect a bug in either the common code in the dh/dz drivers
or getty itself.

Has anyone else seen this problem?
-- 
Ken Mandelberg      |  {akgua,sb1,gatech}!emory!km   USENET
Emory University    |  km@emory                      CSNET,BITNET
Dept of Math and CS |  km.emory@csnet-relay          ARPANET 
Atlanta, Ga 30322   |  Phone: (404) 727-7963