public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Pfiffer <andyp@osdl.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: suparna@in.ibm.com, "Martin J. Bligh" <Martin.Bligh@us.ibm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Faster reboots (and a better way of taking crashdumps?)
Date: 10 Apr 2002 10:58:42 -0700	[thread overview]
Message-ID: <1018461522.4453.212.camel@andyp> (raw)
In-Reply-To: <m1y9fvlfyb.fsf@frodo.biederman.org>

On Wed, 2002-04-10 at 08:40, Eric W. Biederman wrote:

> Unless I missed something the Linux kernel won't work on smp though.
> It is a matter of resetting the state of the apics, and ensuring you
> are running on the first processor.  I don't believe bootimg did/does that.
> 

The copy of bootimg that I have makes no effort to offline CPU's or
reset the APICs.  If there is a newer version, I could not find it.

I have tried 3 different solutions for for Linux-reloading-linux
(bootimg, two-kernel monte, and kexec), and none of them fully support
the kinds of enterprise-class systems we (OSDL) care about:

	1. multiprocessor x86 (p3, p4, +xeons) with APICs
	2. >4GB memory
	3. CPU hotplug
	4. device hotplug
	5. >= 2.5.x kernel

In fact, I have yet to find any variation of linux-loading-linux that
works at all on the 2-way P4-Xeon under my desk or the 8-way P3-Xeon in
the lab.  The only system I have ever seen Two Kernel Monte work on here
is a Celeron-based machine in a nearby cube.

Why do we care about this?  Rebooting these kinds of sytsems can take
several minutes, and in my sample of the systems in the lab, ~80% of the
reboot time is spent slogging through the platform's firmware, ~20% of
the time is spent between LILO and login:.  80% of several minutes is
often greater than the allowable annual downtime for some enterprise
systems.

What about LinxuBIOS?  While an attractive solution for many, it is a
long, uphill battle to add support for chipset after chipset, and
motherboard after motherboard.

The >4GB of memory problem is an interesting quirk -- if the
linux-loading-linux implementation assumes that it can perform the final
copy in 32-bit protected mode *without* paging enabled, it won't
reliably work on >4GB systems.

> In general yes.  There are some interesting side effects though.
> Going through the pci bus and shutting off bus masters is a good
> first approximation of what needs to happen.
> 

The new device model from Pat (mochel@osdl.org) is probably the best way
to go here; you'll be able to walk the driver tree and reliably turn off
devices.

For the CPU side of things, the CPU hotplug work looks promising as
well.

Andy



  reply	other threads:[~2002-04-10 17:58 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-07  1:32 Faster reboots (and a better way of taking crashdumps?) Martin J. Bligh
2002-04-07  2:50 ` Eric W. Biederman
2002-04-07  4:00   ` Martin J. Bligh
2002-04-07  4:12     ` Eric W. Biederman
2002-04-08 14:31   ` Suparna Bhattacharya
2002-04-08 17:09     ` Eric W. Biederman
2002-04-09 15:26       ` Suparna Bhattacharya
2002-04-10 15:40         ` Eric W. Biederman
2002-04-10 17:58           ` Andy Pfiffer [this message]
2002-04-11 14:15             ` Suparna Bhattacharya
2002-04-11 15:08             ` Eric W. Biederman
2002-04-16 10:02               ` Pavel Machek
2002-04-16 22:59                 ` Alan Cox
2002-04-11 13:56           ` Suparna Bhattacharya
2002-04-11 15:35             ` Eric W. Biederman
2002-04-12 14:49               ` Suparna Bhattacharya
2002-04-12 17:59                 ` Eric W. Biederman
2002-04-15 10:07                   ` Suparna Bhattacharya
  -- strict thread matches above, loose matches on Subject: below --
2002-04-05 19:13 Martin J. Bligh
2002-04-05 20:47 ` Jeremy Jackson
2002-04-06  1:48   ` Martin J. Bligh
2002-04-06  2:55     ` Jeremy Jackson
2002-04-08  7:20       ` Suparna Bhattacharya
2002-04-11  3:47         ` Jeremy Jackson
2002-04-11 14:28           ` Suparna Bhattacharya
2002-04-06 17:56 ` Alan Cox
2002-04-07  1:35   ` Martin J. Bligh
2002-04-06 23:27 ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1018461522.4453.212.camel@andyp \
    --to=andyp@osdl.org \
    --cc=Martin.Bligh@us.ibm.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=suparna@in.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox