From owner-freebsd-scsi Sat Jul 12 22:11:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA05883 for freebsd-scsi-outgoing; Sat, 12 Jul 1997 22:11:24 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id WAA05873 for ; Sat, 12 Jul 1997 22:11:09 -0700 (PDT) Received: (qmail 28877 invoked by uid 1000); 13 Jul 1997 05:11:04 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199707130138.SAA14919@ns2.yahoo.com> Date: Sat, 12 Jul 1997 22:11:04 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: filo@yahoo.com Subject: Re: problems with reboot Cc: freebsd-SCSI@FreeBSD.ORG, dg@root.com Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi David Filo; On 13-Jul-97 you wrote: ... > umount(2) does wait correctly. The problem in this case was that the > DPT driver was timing out the "ALLOW MEDIA REMOVAL" command sent to > the controller before it had a chance to finish flushing its cache. > The problem went away when I removed "options DPT_HANDLE_TIMEOUTS" > from the kernel config. The result of this was that the "ALLOW MEDIA > REMOVAL" command was allowed to complete, umount waited around, and > everything shutdown cleanly. Ah... Work from incomplete dataset and you are asured bad results... This is probably why it ``does not happen here'' (hate that expresion). > If this explanation is correct, the DPT driver should be changed to > not timeout the "ALLOW MEDIA REMOVAL" when the DPT_HANDLE_TIMEOUTS > option is being used. What should be done is disable DPT_HANDLE_TIMEOUTS as a default. The DPT firmware knows how to timeout better than you and me. This is what we pay for :-) The DPT_HANDLE_TIMEOUTS option is there only to allow broken hardware to install, so that testing can be conducted. I had a report form a user who loaded the card to a max, pressed the reset button only to find corrupt filesystemsupon reboot. You simply CANNOT do that with a standard DPT configuration. We are building a non-stop FreeBSD based transaction processor here. To acomplish this level of reliability, you need to: Disable the DPT from resetting when the CPU resets, setup all the caches as write-through (including those on the disk drives), and assure an N+1 power to the CPU. In a stand-alone PC environment, you will get a very high degree of reliability if you simply have a descent UPS protecting the AC to your computer and stay away from the reset button. Simon