magi@deepthot.UUCP (David Wiseman) (05/22/84)
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)