jstewart@ccs.carleton.ca (John Stewart) (01/17/91)
I have a telebit modem connected directly to an async port on our Sun 4/380 machine. The port is configured for bidirectional uucp connections. Up until recently it has functioned flawlessly. On several occasions in the last two weeks, the port has got into a state in which DTR is not present. When this happens, the modem of course refuses to answer incoming calls. uucp is still able to initiate outgoing calls. It's a real disaster when this happens because some of my uucp connections are unidirectional (ie. they call me and I cannot call them) and a backlog quickly develops. In this state, getty is still running and restarting getty does not fix the problem. If stty is used to look at the port parameters, the stty process hangs before printing anything and cannot be aborted with ^C. The only solution I have found is to reboot the machine, which isn't too popular with users running long jobs. I'd sure appreciate any hints as to what is causing this problem and how I can fix it without having to reboot the machine.
wolfgang@uunet.uu.net (Wolfgang S. Rupprecht) (01/29/91)
jstewart@ccs.carleton.ca (John Stewart) writes: >On several occasions in the last two weeks, the port has got into a state >in which DTR is not present. When this happens, the modem of course >refuses to answer incoming calls. uucp is still able to initiate outgoing >calls. I see the same behavior on an SLC running sunos 4.1 and a tb+. It appears to only happen on line power going away for the modem *and* cpu. Rebooting the SPARC with the modem still on fixes the problem. I have noticed problems with what appears to be soft-configuration code in the Sun. It looks like the Sun tries to configure the driver to ignore certain modem control lines. To see this bug in action force DSR false. Reboot. Notice that DCD is still false on the wire from the modem. The Sun code will think that DCD is *always* present. It looks like lack of DSR causes the tty driver to generate software-DCD. Perhaps the "DTR hang" is a related problem induced by all of the modem control lines being false while the modem is doing its self test. Wolfgang Rupprecht wolfgang@wsrcc.com (or) uunet!wsrcc!wolfgang Snail Mail Address: Box 6524, Alexandria, VA 22306-0524
wolfgang@uunet.uu.net (Wolfgang S. Rupprecht) (02/22/91)
tbr@tfic.bc.ca (Tom Rushworth) writes: [re: DTR hang on the Sparc] >Have you tried killing the offending getty? (Much simpler if it works...) At that time I only saw the problem once - on power up (I thought). I rebooted afer a few tries at killing it. Another defective getty just came back. Note: This problem didn't prevent calls out, only calls in. The problem with the "ioctl(TCGETS)" is different. Since my last message things have gotten worse, in fact, ever since I turned on CTS-RTS handshaking. Now I get the same ioctl(TCGETS) problem also. This happens a few times per day. Dial outs don't work until this getty gets out of the way. Feb 15 10:49:53 wsrcc getty: ioctl(TCGETS): Bad file number Feb 15 10:49:53 wsrcc getty: ioctl(TCGETS): Operation not supported on socket I just set up getty on the modem line to timeout in 60 seconds. This usually frees up the port in a minute or two. Things are normal afterwords. My setup: Sparc SLC, SunOS 4.1, TB+ Version BA4.00. CTS-RTS on in both /etc/uucp/Systems and in /etc/gettytab, CTS-RTS off in the eeprom, Hw CD on in the eeprom. / tttya-mode=19200,8,1,n,- / ttya-rts-dtr-off=true / ttya-ignore-cd=false. I am sure glad that "the network is the computer". The serial port certainly isn't. ;-) -wolfgang PS. Please don't get me wrong - in general I *love* my SLC. I just hate it when I don't have sources to a broken program - so I can't even try to dive in and fix it. This is damn frustrating. Wolfgang Rupprecht wolfgang@wsrcc.com (or) uunet!wsrcc!wolfgang Snail Mail Address: Box 6524, Alexandria, VA 22306-0524