Date: Sat, 12 Jul 1997 15:17:28 -0400 (EDT) From: Chuck Robey <chuckr@glue.umd.edu> To: Simon Shapiro <Shimon@i-Connect.Net> Cc: dg@root.com, filo@yahoo.com, freebsd-SCSI@FreeBSD.ORG Subject: Re: problems with reboot Message-ID: <Pine.BSF.3.96.970712151441.28420C-100000@Journey2.mat.net> In-Reply-To: <XFMail.970712115005.Shimon@i-Connect.Net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 12 Jul 1997, Simon Shapiro wrote: > > Hi David Greenman; On 12-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. > > I have not checked the code in this area, but all that I think is necessary > is for the umount(2) syscall to wait and block shutdown until it returns. > Under normal operation, it generates the SCSI ``ALLOW MEDIA REMOVAL'', > which the DPT blocks until it is done flushing and invalidating. > I personally never have this problem on any of our machines, but... Is this always safe? I've had some instances where a umount call simply hung, and never returned. I think they were either nfs or msdos mounts that gave this trouble, but the umount call could not be kill'ed, and making shutdown wait? Would halt still work, as an emergency measure? I know the FSs that were hung wouldn't be closed, but at least my ufs FSs would be clean. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+-----------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.970712151441.28420C-100000>