From owner-freebsd-questions  Wed Feb  5 22:52:12 1997
Return-Path: <owner-questions>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id WAA10373
          for questions-outgoing; Wed, 5 Feb 1997 22:52:12 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA10341;
          Wed, 5 Feb 1997 22:52:09 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id RAA10833; Thu, 6 Feb 1997 17:48:56 +1100
Date: Thu, 6 Feb 1997 17:48:56 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199702060648.RAA10833@godzilla.zeta.org.au>
To: hackers@freebsd.org, questions@freebsd.org, stesin@gu.net
Subject: Re: Strange(!!) sio callin/callout behaviour in 2.1.6
Sender: owner-questions@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>I observe the following misbehaviours with regard to sio
>driver:
>
>1. pppd never seems to receive/handle a SIGHUP from modem.

Perhaps the modem never hangs up.

>2. Callout devices behavior screwed... example: say I take the sio
>   unit 5, getty active on ttyd5, TR LED on modem is on, then:
>
>   # stty -a -f /dev/ttyd5
>   [...a screen of stty's output goes here, Ok...]
>   # stty -a -f /dev/cuaa5
>   stty: /dev/cuaa5: Device busy
>   # cu -l /dev/cuaa5 -s 57600
>   cu: /dev/cuaa5: Line in use
>   #

This means that something has /dev/ttyd5 open.  Perhaps getty succeeds
in opening a few microseconds after pppd closes /dev/cuaa5.  getty sleeps
until carrier is present, but no longer, so if the port is shared between
a getty and a dialout program like pppd and the dialout program closes
the dialout port before carrier drops, then the getty will grab the port.
HUPCL on the dialout port and a sufficiently large dtrwait should prevent
this from happening if the modem responds to DTR dropping sufficent quickly.

Bruce