Inexplicable loss of DTR on async port
Wolfgang S. Rupprecht
wsrcc!wolfgang at uunet.uu.net
Fri Feb 22 07:15:00 AEST 1991
tbr at 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 at wsrcc.com (or) uunet!wsrcc!wolfgang
Snail Mail Address: Box 6524, Alexandria, VA 22306-0524
More information about the Comp.sys.sun
mailing list