From owner-freebsd-scsi Mon Jul 14 19:54:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA00755 for freebsd-scsi-outgoing; Mon, 14 Jul 1997 19:54:31 -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 TAA00747 for ; Mon, 14 Jul 1997 19:54:27 -0700 (PDT) Received: (qmail 5662 invoked by uid 1000); 15 Jul 1997 02:54:38 -0000 Message-ID: X-Mailer: XFMail 1.1 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199707131555.JAA25833@pluto.plutotech.com> Date: Sun, 13 Jul 1997 14:01:42 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: "Justin T. Gibbs" Subject: Re: problems with reboot Cc: freebsd-SCSI@FreeBSD.ORG, filo@yahoo.com, dg@root.com Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Justin T. Gibbs; On 13-Jul-97 you wrote: > >>There is an issue with FreeBSD shutdown not waiting for the DPt to > flush > >>caches as it should. > > > > Should be easy to fix by adding a shutdown routine to the driver that > waits > >for the flushes to complete. > > > >-DG > > > >David Greenman > >Core-team/Principal Architect, The FreeBSD Project > > If we're not waiting for the last close to complete, that is a bug > that should be fixed. I believe that Simon added a syncronize > cache command into sdclose which should address the DPT issue so > long as it actually gets performed and we wait for it to complete. > The syncronize cache command may be required for other disk devices > as well, and a generic solution is always better than a controller > specific one. I belive this discussion is a bit out of sync; * The curent SCSI layer (sd.c in particular) is doing the right thing: It issues a ``PREVENT MEDIA REMOVAL'' SCSI command on open, and ``ALLOW MEDIA REMOVAL'' on close. It waits for these tom complete before returning. * The DPT firmware does the right thing by enabling caches (within the constraints put by its configuration) on the indicated device(s) on ``PREVENT...'' and disabling and flushing on ``ALLOW...''. It also blocks until such activities are done. * It appears that the shutdown procedure does a umount -a and that umount issues a close to sd.c... * I confused the issue (while trying to help some early DPt adopters), by introducing a timeout mechanism of my own in the DPT driver. This OPTIONAL and DANGEROUS option can timeout the ``ALLOW...'' command. If you have this option enabled, and shutd down immediately after (or during) very heavy disk write activity, the caches may not have a chance to flush. * Use these DPT options only if I ask you to. Under normal operation there is absolutely NO NEED to timeout the DPT. Ever. The reason we use this option is that, under certain hardware configurations, the DPT will send a completion to the driver and the driver will not see it. In this case, and in this case only, do we timeout the command, so that we can have the system not hang, waiting for an event that will never happen. * 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 on open/close and then have to do all manners of ugly thins to get out of the mess. FreeBSD is the first I know which solved this problem so elegantly (at a perormance cost to open-sort-I/O-close sequences). Hope this helps. Simon