Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 18 Oct 1998 17:09:52 -0600
From:      "Justin T. Gibbs" <gibbs@plutotech.com>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        gibbs@plutotech.com (Justin T. Gibbs), dkelly@hiwaay.net, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG
Subject:   Re: filesystem safety and SCSI disk write caching 
Message-ID:  <199810182316.RAA21632@pluto.plutotech.com>
In-Reply-To: Your message of "Sun, 18 Oct 1998 19:24:58 -0000." <199810181924.MAA19638@usr06.primenet.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
>> And why do you think the drive didn't bother to commit the data even
>> though power was constantly supplied to the drive and only a few,
>> recent transactions were lost?  Most likely because hitting the
>> reset switch caused a power glitch that reverted the drive to its
>> power on state.
>
>I think it's because the PCI bus POSTed the controller, resulting in
>a SCSI reset, which lost the uncommitted data.

On a Hawk?  I've never seen one respond incorrectly to a bus reset 
condition.  We're also talking about several seconds of delay before the
reset occurs (more than the few ms wait before the hawk will flush its 
cache) since the aic7xxx chips will not assert the reset line
until the BIOS has been installed (i.e. hitting the chip reset or POSTing
the chip will not cause a spurious bus reset).

>It's a lot easier to believe that than to believe the other.

Not really.  Hawks have had a very good firmware record and the only way
that this could happen in your scenario would be because of a firmware
bug.

>I suppose we should test by making a loadable system call that directly
>calls the reset code, so as to put the "reset causes a reset reliably,
>but even though no hardware other than the disk write cache is
>affected, we believe it's because no one debounced the switch" theory
>to rest.

Who needs a system call?  The user can easily cause a bus reset to occur
by opening the XPT device and sending a ccb with the XPT_RESET_BUS
function code in it.  The alternative is to put the drive on a separate
power supply.

--
Justin



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810182316.RAA21632>