smk@Mitre-Bedford@sri-unix (09/16/82)
Date: Mon Sep 13 14:43:51 1982 ---------------------- Some of you may know the problem . . . ------- Forwarded Message Date: 11 Sep 1982 12:18-PDT From: txr at usc-cse Subject: UNIX on Micom Micro600 To: smk at Mitre-Bedford In-Reply-To: smk's message of Wed Sep 8 215149 1982 Origin: usc-cse If you have UNIXen attached to a Micom, maybe you know something I don't. Our vax 11/750 (it should be the same on a 780) is attached to a Micro600 port selector, and we are continually losing lines (the Micro600 puts the "Out of Service") due to the way UNIX handles DTR. I've tried hacking the terminal driver to do the right thing, but for reasons I don't fully understand things still aren't quite right. So, do you have problems with the Micro600 getting confused about the state of the wires? (For us this is especially a problem when the machine is coming up.) Have you done anything special to UNIX (either the kernel or things like init, getty, login) to make the Micro600 happy? I've been struggling with this problem for a while, I'd be **really** happy for any help you could give me. thanks, Tim Rentsch ------- End of Forwarded Message Here's a solution: 2 parts -- 1st part: For 4.1bsd to work with the micom, the VAX must work the RS-232 protocol properly. To do this, code must be inserted into getty.c to have a HUPCL ioctl done on the line and the flags for the line in the config file for vmunix must have modem control set (the flag bit = 0). We got a little fancy and restricted getty to doing the HUPCL on /dev/tty[d-fp]? and inserted a timeout on these lines that was read from /etc/timeout. We also put in timeouts into login.c and force.c, a program that sends SIGHUP to all processes on a terminal that hasn't been used for some time (currently 30 mins.). We use the st_atime field to determine idle time. A warning precedes the force by a minute. So, when getty or login dies, the terminal is electrically closed and the RS232 protocol between the MICOM and the VAX understand each other. (Without the HUPCL ioctl, the VAX won't drop the line.) part 2: Maybe owing to the non-handling of RTS-CTS by 4.1bsd DH/DZ drivers or a MICOM600 bug, or whatever, the MICOM still goes out-of-service (or something equally bad happened). We cut the CTS line at the MICOM600 and everything works hunky-dory.