From owner-freebsd-current Sun Sep 10 21:31: 7 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 3966337B422 for ; Sun, 10 Sep 2000 21:31:02 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id PAA06627; Mon, 11 Sep 2000 15:24:26 +1100 Date: Mon, 11 Sep 2000 15:24:24 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: Tor.Egge@fast.no, current@FreeBSD.ORG Subject: Re: Dirty buffers on reboot.. In-Reply-To: <200009110049.RAA28932@pike.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 10 Sep 2000, John Baldwin wrote: > Tor.Egge@fast.no wrote: > > > Ok, an update on the dirty buffers on reboot: > > > > > > If you use the reboot command, you will get dirty buffers. If you use > > > 'shutdown -r now' instead, you won't get dirty buffers. Thus, as a workaround > > > for now, use the shutdown command to reboot your box until we can track this > > > down. I haven't noticed this yet. I normally use reboot. > > I suggest using some method to allow interrupt threads to run during > > the shutdown. Perhaps the current process priority should be elevated > > so it is guaranteed to be scheduled after the last interrupt thread > > instead of some unrelated process. I'm surprised they get stopped. At least writing buffers in sync() depends on interrupts working. There is a problem for syncing in panic(). Interrupts (and tsleep()) shouldn't work in panic(), especially for panics in interrupt context. They used to sort of work by doing splx(safepri). This corresponds to blowing open all locks. > > RCS file: /home/ncvs/src/sys/kern/kern_shutdown.c,v > > retrieving revision 1.80 > > ... > > @@ -247,7 +248,18 @@ > > break; > > printf("%d ", nbusy); > > sync(&proc0, NULL); > > - DELAY(50000 * iter); > > + > > + if (curproc != NULL) { > > curproc is never NULL anymore, so the if statement can be removed. Can't it happen for panics while cold? The code "if (p && p != idleproc ...)" in uprintf() seems to be to handle this. We still have lots of (p == NULL) checks where coldness probably isn't an issue. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message