public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Andy Pfiffer <andyp@osdl.org>
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: 11 Apr 2002 09:08:44 -0600	[thread overview]
Message-ID: <m1pu16l1c3.fsf@frodo.biederman.org> (raw)
In-Reply-To: <1759496962.1018114339@[10.10.2.3]> <m18z80nrxc.fsf@frodo.biederman.org> <3CB1A9A8.1155722E@in.ibm.com> <m1ofgum81l.fsf@frodo.biederman.org> <20020409205636.A1234@in.ibm.com> <m1y9fvlfyb.fsf@frodo.biederman.org> <1018461522.4453.212.camel@andyp>

Andy Pfiffer <andyp@osdl.org> writes:

> 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

kexec should handle.
        1. multiprocessor x86 (p3, p4, +xeons) with APICs
        2. >4GB memory
        3. >= 2.5.x kernel
        4. potentially non-x86.
 
> 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.

Interesting.  I know I have it runs on the 2-way P4-Xeon under my
desk.  So maybe it is a compiler bug, or some weird firmware case I
don't handle correctly.
 
> 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.

Sure it will, if it only allocates the memory from the low 4GB, in fact
my kexec code makes certain to allocate memory from the kernel address
space.  get_free_page() in ZONE_NORMAL.  This is the low 896MB.  So
there shouldn't be a problem.  This was done very deliberately so it
would work on these kinds of 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.

I totally agree.  Walking the driver tree is exactly what I want.
Disabling bus masters is just a quick hack to rule out a DMA killing
your linux booting linux.

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

Interesting.  So far I haven't seen a system that supports CPU hot
plug, on x86 so I have no clue here.

Eric

  parent reply	other threads:[~2002-04-11 15:15 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
2002-04-11 14:15             ` Suparna Bhattacharya
2002-04-11 15:08             ` Eric W. Biederman [this message]
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=m1pu16l1c3.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=Martin.Bligh@us.ibm.com \
    --cc=andyp@osdl.org \
    --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