km@emory.UUCP (02/25/87)
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-7963roy@phri.UUCP (02/28/87)
In article <1995@emory.UUCP> km@emory.UUCP writes: > We have been having the following problem on 4.3BSD (acutally the > Mt Xinu release) [...] Getty does not always raise DTR on its port. Perhaps this is too trivial to even mention, but I'll mention it anyway. On 4.2, the dmf lines are called h0->hf, i0-if, etc. Under 4.3 they are called A0->A7, B0->B7, C0->C7, etc. Also the /etc/ttys file has been completely restructured. The conversion is straight-forward, but tedious to implement (i.e. involves a fair amount of manual editing). Between the renaming of the tty lines and the merging of several files into one (both good things, BTW) we managed to botch a few things in our new /etc/ttys file at first. This caused random strange things to happen, some of which match your symptoms. Could this possibly be the cause of some of your problems? For some more conventional suggestions, check the dmf flags in your config file to make sure modem control is {en,dis}abled on the right lines (another thing we botched on the first go-round). Make sure acucntrl isn't playing games on you; try making all your modems unidirectional until you figure out what's wrong, simply to reduce the number of variables. If you're using a mix of Emulex CS-21's and DEC DMF-32's, remember that only the first two lines on the DEC board have modem control, and that while all the Emulex lines do, it doesn't quite match that on the DEC board. BTW, can somebody explain to me why the DEC DMF-32, with all the zillions of random modem signals it lets you get at, still doesn't let you read the HS line? It sure would be a nice way to autobaud a 1200/2400 modem (as in that's what the signal is designed for). While I'm at it, fie on US Robotics for not making their Courier toggle HS when it makes a connection at 1200. For all the braindamage my old CTS-2424 had, at least it did this properly. RS-232 is such a wonderful standard -- with 25 signals, there are (at least) 2^25 ways to implement it, and I'm sure if you looked long enough you would find at least one manufacturer who had implemented each one. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 "you can't spell deoxyribonucleic without unix!"
generous@dgis.UUCP (02/28/87)
In article <2603@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >In article <1995@emory.UUCP> km@emory.UUCP writes: >> We have been having the following problem on 4.3BSD (acutally the >> Mt Xinu release) [...] Getty does not always raise DTR on its port. > > For some more conventional suggestions, check the dmf flags in your >config file to make sure modem control is {en,dis}abled on the right lines > ... >you're using a mix of Emulex CS-21's and DEC DMF-32's, remember that only >the first two lines on the DEC board have modem control, and that while all >the Emulex lines do, it doesn't quite match that on the DEC board. > About 16 months ago, I ran into the same problem that km@emory had with the modem control signals on a DEC DMF-32, under More/bsd (Mt. Xinu's 4.2 bsd), running on a 11/750. I eventually discovered the same two remedies that roy@phri mentions: 1) you need the proper flags set in your /sys/conf/HOST file (and then make sure you run config, make depend, make ... :-) 2) make sure that you only use the first 2 ports But I also discovered one more thing was needed to get the ports to work: 3) You needed to use a program called "/etc/ttyconfig". This is a Mt Xinu's unique program? (as far as I know), and it allowed the control some on those signals. I am telling this all from memory, as I don't have access to this host anymore. I also remeber having a hard time finding any info on "ttyconfig", as there wasn't a man page available. (Maybe Ed Gould can tell us more about it?) By the way, the version of the DMF-32 driver that we had from Mt. Xinu also supported the parallel port (we had a printer attacher to it). Has any one out there written a driver to also support the synchronous port? Hope this helps: -curtis- ====================================== Curtis C. Generous Lawrence Livermore National Labs ARPA: generous@lll-tis-b.ARPA UUCP: {seismo,vrdxhq}!dgis!generous
km@emory.UUCP (Ken Mandelberg) (03/15/87)
In article <1995@emory.UUCP>, km@emory.UUCP (Ken Mandelberg) writes: > 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). > > 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. I want to thank Doug Hosking (convex!hosking) for putting his finger on the problem. The problem was being induced by leaving processes running on the port after logout. When the process finally terminates it does the last close on the tty (the new getty is waiting for a connection and has not yet opened the tty), which drops DTR. The getty will then sit forever with DTR off and no chance to see a DCD. The offending code in the device specific close routine is: dz: if ((tp->t_state&(TS_HUPCLS|TS_WOPEN)) || (tp->t_state&TS_ISOPEN) == 0) (void) dzmctl(dev, DZ_OFF, DMSET); dh (or dmf): if (tp->t_state&TS_HUPCLS || (tp->t_state&TS_ISOPEN)==0) dmctl(unit, DML_OFF, DMSET); My inclination is to replace the test in both cases with: if ((tp->t_state&TS_HUPCLS && (tp->t_state&TS_WOPEN ==0)) || ((tp->t_state&TS_ISOPEN)==0)) ie. I think you should drop DTR if HUPCLS is set, but WOPEN is not. There is much that makes no sense to me in the existing code. For example: 1) Why is TS_ISOPEN being tested as an alternate conditon for dropping DTR? I think that condition should never happen. If I am in the device specific close routine, the device must be open. I perpetuate this code in my replacement, but think it is extraneous. 2) Why is the existing dh and dz code different? Is there some hardware issue that separates them. 3) The test in the existing dz code seems bizarre. It drops DTR if EITHER HUPCLS or WOPEN is set. Does that make any sense? -- 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