From owner-freebsd-scsi  Tue Jul 15 03:55:02 1997
Return-Path: <owner-freebsd-scsi>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id DAA20672
          for freebsd-scsi-outgoing; Tue, 15 Jul 1997 03:55:02 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA20654
          for <freebsd-SCSI@FreeBSD.ORG>; Tue, 15 Jul 1997 03:54:52 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id UAA16854; Tue, 15 Jul 1997 20:50:23 +1000
Date: Tue, 15 Jul 1997 20:50:23 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199707151050.UAA16854@godzilla.zeta.org.au>
To: gibbs@plutotech.com, Shimon@i-Connect.Net
Subject: Re: problems with reboot
Cc: dg@root.com, filo@yahoo.com, freebsd-SCSI@FreeBSD.ORG
Sender: owner-freebsd-scsi@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>*  It appears that the shutdown procedure does a umount -a and that umount
>   issues a close to sd.c...

Open swap devices prevent the last close in some cases.

>*  I further confused the issue by ASKING ``Does the /sbin/reboot command 
>   umount or not?''  I then added that, if memory does not fail me, UnixWare
>   equivalent of /sbin/reboot does not and indeed can cause this sort of
>   failure.  BTW, most other O/S do NOT issue the ``PREVENT/ALLOW...'' pairs

It does for clean shutdowns only.  If syncing all busy buffers succeeds,
then all file systems are unmounted.   Otherwise, file systems are not
unmounted.

Summary: this doesn't work quite right yet.

Bruce