DTR Problems

Ken Mandelberg km at emory.UUCP
Sun Mar 15 09:45:56 AEST 1987


In article <1995 at emory.UUCP>, km at 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 at emory                      CSNET,BITNET
Dept of Math and CS |  km.emory at csnet-relay          ARPANET 
Atlanta, Ga 30322   |  Phone: (404) 727-7963



More information about the Comp.unix.wizards mailing list