Date: Sat, 12 Jul 1997 22:11:04 -0700 (PDT) From: Simon Shapiro <Shimon@i-Connect.Net> To: filo@yahoo.com Cc: freebsd-SCSI@FreeBSD.ORG, dg@root.com Subject: Re: problems with reboot Message-ID: <XFMail.970712221104.Shimon@i-Connect.Net> In-Reply-To: <199707130138.SAA14919@ns2.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970712221104.Shimon>