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