Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ut-sally!husc6!linus!gatech!akgua!emory!km From: km@emory.UUCP (Ken Mandelberg) Newsgroups: comp.unix.wizards Subject: Re: DTR Problems Message-ID: <2010@emory.UUCP> Date: Sat, 14-Mar-87 18:45:56 EST Article-I.D.: emory.2010 Posted: Sat Mar 14 18:45:56 1987 Date-Received: Mon, 16-Mar-87 04:20:00 EST References: <1995@emory.UUCP> Organization: Math & Computer Science, Emory University, Atlanta Lines: 56 Keywords: DTR getty dh dz cs11 cs21 Summary: DTR Problem identified 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