From owner-freebsd-hackers  Sun Jul 23 09:41:37 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.11/8.6.6) id JAA06344
          for hackers-outgoing; Sun, 23 Jul 1995 09:41:37 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id JAA06328
          for <hackers@freebsd.org>; Sun, 23 Jul 1995 09:41:30 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id CAA17954; Mon, 24 Jul 1995 02:41:15 +1000
Date: Mon, 24 Jul 1995 02:41:15 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199507231641.CAA17954@godzilla.zeta.org.au>
To: hackers@freebsd.org, nc@ai.net
Subject: Re: Problem w/ serial ports going busy.
Sender: hackers-owner@freebsd.org
Precedence: bulk

>I have several cuaa ports set up to handle dial ins. At odd times the 
>ports will just go busy [i.e. Kermit says, "Sorry, can't open connection: 
>/dev/cuaa1: Device Busy"]

This error occurs in the following cases:

1) /dev/cuaa1 is already open and is in exclusive mode.
2) /dev/ttyd1 is already open.
3) /dev/ttyd1 was opened (in nonblocking mode) while it was and still is
   being opened (in blocking mode), and your version of FreeBSD has broken
   `last close' handling in vfs (all versions except 1.1.5+patches are
   broken here).

Case 3) is quite common.  It happens whenever there is a getty sleeping in
open for /dev/ttyd1 and you do `stty -f /dev/ttyd1'.  Vfs counts opens
before they succeed.  Thus the open count is 1 when getty goes to sleep.
After stty opens the device, the device is active and the open count is 2.
After stty closes the device, the open count is 1 and the device is still
active because vfs only informs device drivers about last closes (open count
== 0).

>Nothing is running except getty on those ports [and when I kill getty the 
>device doesn't get freed] and the modems are configured perfectly.

This fails to fix case 3) because:

a) the driver doesn't clear the busy flag.  It has no way of knowing that
   the nonblocking open isn't still active.
b) the device isn't open so exit() doesn't close it.  The device close
   function never gets called.

Case 2) can be hard to fix because close() can hang waiting to flush output.

>Any ideas [even dirty ways] of forcing the ports un-busy? I really hate 
>having to reboot the machine to get things working.

Run a program that holds /dev/ttyd1 open and kill getty while the port is
open.  Any terminal program that doesn't wait for carrier should do.

Bruce