Strange problem with 4.2 init

[David Wiseman]

Ok guys, I got a stange one for you.....

Problem:
	A gandalf PACX unit (switcher) which requires an annoyingly long
	period of time to recognize that a host has dropped DTR. (Seems to
	need at least 1 second to recognize the drop, 2 seconds is better.)

Simple fix:
	Get init to sleep after the fork and before the first open of the
	terminal. This allows the PACX time to realize things have changed
	and drop the connection to the terminal; when the open is finally
	executed, it will hang waiting for DTR from the PACX which won't be
	asserted until there is a terminal wanting to connect.

	Simple huh? And it works under V7, 2.8, 4.1, PWB, etc. After all
	what can a simple sleep do to muck things up?

New Problem:
	It doesn't work. If we sleep (or in fact, cause a delay by counting
	down to zero from some large number) the kernel never sees DTR being
	raised by the PACX. The PACX unit happily connects to the ports,
	having been assured that a host is there (after all, the host raised
	DTR) and then nothing happens; no login prompt, no nothing. A ps axl
	shows the inits waiting in the terminal driver (a DH), assumably
	for DTR from the PACX. 

	Please, I am not ready to believe that having init sleep for
	a period of time causes the PACX to forget to raise DTR. In fact,
	digging deeper into init code shows that if init finds itself
	about to exec the 5th copy of getty on a line in a minute, it 
	complains bitterly and goes to sleep for 30 seconds. I forced this
	to happen and, believe it or not, things work! The PACX reconnects
	just like it is supposed to. But, just trying to sleep for 30 
	seconds before the open doesn't work.


Question:
	Has anyone out there seen this before? If so, please help me!

Other things:
	I suppose I should say that we are running a VAX 11/750 with an
	Able DHDM. 

magi
-- 
magi	(David Wiseman @ UWO CS London Canada)