From owner-cvs-all  Wed Jul 29 10:18:54 1998
Return-Path: <owner-cvs-all>
Received: (from daemon@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id KAA06314
          for cvs-all-outgoing; Wed, 29 Jul 1998 10:18:54 -0700 (PDT)
          (envelope-from owner-cvs-all)
Received: from vader.cs.berkeley.edu (vader.CS.Berkeley.EDU [128.32.38.234])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA06290
          for <committers@FreeBSD.ORG>; Wed, 29 Jul 1998 10:18:44 -0700 (PDT)
          (envelope-from asami@vader.cs.berkeley.edu)
Received: from silvia.HIP.Berkeley.EDU (sji-ca7-55.ix.netcom.com [209.109.235.55]) by vader.cs.berkeley.edu (8.8.7/8.7.3) with ESMTP id KAA22799; Wed, 29 Jul 1998 10:18:10 -0700 (PDT)
Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.8/8.6.9) id KAA02374; Wed, 29 Jul 1998 10:18:07 -0700 (PDT)
Date: Wed, 29 Jul 1998 10:18:07 -0700 (PDT)
Message-Id: <199807291718.KAA02374@silvia.HIP.Berkeley.EDU>
To: imp@village.org
CC: committers@FreeBSD.ORG
In-reply-to: <199807290230.UAA27961@harmony.village.org> (message from Warner Losh on Tue, 28 Jul 1998 20:30:23 -0600)
Subject: Re: very quick reboot
From: asami@FreeBSD.ORG (Satoshi Asami)
Sender: owner-cvs-all@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

 * 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