Date: Sun, 13 Jul 1997 14:01:42 -0700 (PDT) From: Simon Shapiro <Shimon@i-Connect.Net> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: freebsd-SCSI@FreeBSD.ORG, filo@yahoo.com, dg@root.com Subject: Re: problems with reboot Message-ID: <XFMail.970714195438.Shimon@i-Connect.Net> In-Reply-To: <199707131555.JAA25833@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970714195438.Shimon>