Date: Sun, 10 Sep 2000 23:55:54 -0700 (PDT) From: John Baldwin <jhb@pike.osd.bsdi.com> To: Bruce Evans <bde@zeta.org.au> Cc: Tor.Egge@fast.no, current@FreeBSD.ORG Subject: Re: Dirty buffers on reboot.. Message-ID: <200009110655.XAA36296@pike.osd.bsdi.com> In-Reply-To: <Pine.BSF.4.21.0009111509410.606-100000@besplex.bde.org> from Bruce Evans at "Sep 11, 2000 03:24:24 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote:
> 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.
It is probably a timing issue more than anything else. :-/
> > > 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.
Hmm. By calling mi_switch() we end up giving up both shced_lock and Giant,
so that this is equivalent for the time being to "blowing open all the 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.
Hmmmm. At least on the x86, curproc is now set to proc0 before we probe
to see how much memory we have in init386(). In fact, we set curproc up
right after setting up the GDT, and before both the ldt and idt, so at least
on x86, we won't get a trap with curproc == NULL. :) On the alpha I'm not
as sure. Hmm, after looking, we set curproc in alpha_init(), but we do
it much later on. I'm not sure if we have enabled interrupts at that point
or not.
> Bruce
--
John Baldwin <jhb@bsdi.com> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009110655.XAA36296>