Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: wsrcc!wolfgang@uunet.uu.net (Wolfgang S. Rupprecht)
Newsgroups: comp.sys.sun
Subject: Re: Inexplicable loss of DTR on async port
Keywords: Hardware
Message-ID: <1467@brchh104.bnr.ca>
Date: 28 Jan 91 16:34:43 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 23
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v10n20
X-Sun-Spots-Digest: Volume 10, Issue 28, message 16
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

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