Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Jul 1998 10:18:07 -0700 (PDT)
From:      asami@FreeBSD.ORG (Satoshi Asami)
To:        imp@village.org
Cc:        committers@FreeBSD.ORG
Subject:   Re: very quick reboot
Message-ID:  <199807291718.KAA02374@silvia.HIP.Berkeley.EDU>
In-Reply-To: <199807290230.UAA27961@harmony.village.org> (message from Warner Losh on Tue, 28 Jul 1998 20:30:23 -0600)

next in thread | previous in thread | raw e-mail | index | archive | help
 * Unless the hardware is in a weird state, that should almost work.

I guess "real" reboots are for stuff like that.... :)

 * You'd also have to bzero the bss section of the kernel as well as
 * recreate the boot information that was passed to the kernel from the
 * boot blocks.

Ok.  Mike Smith also commented that we want to skip over that part.

 * The only thing that I'd worry about would be hardware that is set to a
 * known state by the bios that FreeBSD then sets to a different known
 * state which would be FUBAR'd if FreeBSD were to set that state again.

Hmm.

 * Video might also be a problem, but since we can now make 16-bit BIOS
 * calls, it should be less of a problem.

I'm not sure what you mean, but I'm assuming the X server is shut down 
properly, so that should reset the video state, right?

 * There are likely other things that I've forgotten...
 * 
 * I'm curious... why do you want to do this?

To make the machine reboot faster? :)

Actually, it was just that I'm getting tired of waiting for the
machine with 3 twin-channel SCSI adapters with 96MB of memory to go
through the hardware reboot.  (It takes like a minute before the boot
prompt even shows up on the serial console!)

Also, we are experimenting with a setup that minimizing downtime of
individual machines is critical for the reliability of the entire
cluster.  Shaving off a minute from the rebooting time will do wonders
to our numbers.

By the way, I don't suppose we can skip the probes (with calls to
suitable alternate initialization routines), right?  That part of
memory is not write protected, so we can't assume it's not damaged if
the machine panic's.  Actually, maybe we can, if it's a real clean
reboot.  Hmm.

Satoshi



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807291718.KAA02374>