system@asuvax.UUCP (Marc Lesure) (02/20/85)
We run 4.2bsd on a Vax11/780. We have 4 DEC dz's and 2 Emulex DMF-32's on a single Unibus. The problem we're running into is that the getty's on the DMF's start to die off. I can re-initialize them only by shutdowning the system down or editing /etc/ttys to disable the ports which have died, doing a kill -1 1, and then re-edit ttys to enable the ports with another kill -1 1. Trying to initialize the ports with a kill -1 1 prior to editing the file does not work. The getty's die off at random times and on random ports. The DZ's are fine. Does anyone know of a driver bug or had this problem themselves? Does anyone have a more reasonable solution to reactive these ports? Thanks - ------------------------------------------------- Marc Lesure System Manager Engineering Computer Center Arizona State University Tempe, Arizona UUCP: ...!ucbvax!arizona!asuvax!lesure CSNET: lesure@asu
bukys@rochester.UUCP (Liudvikas Bukys) (02/22/85)
> We run 4.2bsd on a Vax11/780. We have 4 DEC dz's and 2 Emulex > DMF-32's on a single Unibus. The problem we're running into is > that the getty's on the DMF's start to die off. I can re-initialize > them only by shutdowning the system down or editing /etc/ttys to > disable the ports which have died, doing a kill -1 1, and then re-edit > ttys to enable the ports with another kill -1 1. Trying to initialize > the ports with a kill -1 1 prior to editing the file does not work. The > getty's die off at random times and on random ports. The DZ's are > fine. Does anyone know of a driver bug or had this problem > themselves? Does anyone have a more reasonable solution to reactive > these ports? Unsaid but probably true is that the DMF lines are attached to a port multiplexor, data switch, or whatever else you want to call it. It is likely that what is happening is that your VAX does not hold DTR down long enough for the switch to notice it, so the switch doesn't consider the previous connection completely closed down yet, and won't allow any more connections to be established to it. The popular quick solution to this is to put a sleep of at least 1 second into /etc/init, just after it fork()s but before it open()s. Liudvikas Bukys rochester!bukys (uucp) via allegra, decvax, seismo bukys@rochester (arpa)
THOMPSON@USC-ECLC.ARPA (mark thompson) (02/22/85)
Putting a 2 or 3 second sleep in init (after the fork) helps a lot. However, you will still need to do more. What we do is have a hack that occasionally goes out and KILLs all of the init forks (except fork 1 of course). -mark -------