From owner-freebsd-scsi Sun Oct 18 16:17:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA18668 for freebsd-scsi-outgoing; Sun, 18 Oct 1998 16:17:10 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA18659; Sun, 18 Oct 1998 16:17:08 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id RAA21632; Sun, 18 Oct 1998 17:16:43 -0600 (MDT) Message-Id: <199810182316.RAA21632@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert 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 In-reply-to: Your message of "Sun, 18 Oct 1998 19:24:58 -0000." <199810181924.MAA19638@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 18 Oct 1998 17:09:52 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> 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