linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: suparna@in.ibm.com
Cc: linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@transmeta.com>,
	Andy Pfiffer <andyp@osdl.org>, Dave Hansen <haveblue@us.ibm.com>,
	wa@almesberger.net
Subject: Re: [PATCH][CFT] kexec (rewrite) for 2.5.52
Date: 03 Jan 2003 03:37:06 -0700	[thread overview]
Message-ID: <m11y3uldt9.fsf@frodo.biederman.org> (raw)
In-Reply-To: <20021231200519.A2110@in.ibm.com>

Suparna Bhattacharya <suparna@in.ibm.com> writes:

> The good news is that it worked for me. Not only that, I have just 
> managed to get lkcd to save a dump in memory and then write it out 
> to disk after a kexec soft boot ! I haven't tried real panic cases yet 
> (which probably won't work rightaway :) ) and have testing and 
> tuning to do. But kexec seems to be looking good.

Nice.  Any pointers besides lkcd.sourceforge.net

For the kexec on panic case there is a little code motion yet to be
done so that no memory allocations need to happen.  The big one is
setting up a page table with the reboot code buffer identity mapped.

I am tempted to do the identity mapping of the reboot code buffer in
init_mm, but for starters I will look at how complex it will be to
have a spare mm just sitting around for that purpose.  When I get
to dealing with the architectures like the hammer, and the alpha where
you always need page tables I will need to develop an architecture
specific hook for building the page tables needed by the
code residing in the reboot code buffer, (because virtual memory
cannot be disabled), but that should be straight forward.

My goal is to have no locks on the kexec part of the panic path.  And
the current memory allocations are the only really bad part of that.

A dump question.  Why doesn't the lkcd stuff use the normal ELF core
dump format?  allowing ``gdb vmlinux core'' to work?

Eric

  reply	other threads:[~2003-01-03 10:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-22 11:07 [PATCH][CFT] kexec (rewrite) for 2.5.52 Eric W. Biederman
2002-12-31 14:35 ` Suparna Bhattacharya
2003-01-03 10:37   ` Eric W. Biederman [this message]
2003-01-03 12:41     ` Suparna Bhattacharya
2003-01-04 20:34       ` Eric W. Biederman
2003-01-04 22:42       ` Eric W. Biederman
2003-01-06  5:48       ` [PATCH] kexec for 2.5.54 Eric W. Biederman
2003-01-07 22:46         ` Andy Pfiffer
2003-01-07 23:01           ` Dave Hansen
2003-01-07 23:11             ` Martin J. Bligh
2003-01-15 19:43         ` [2.5.58][KEXEC] Success! (using 2.5.54 version + kexec tools 1.8) Andy Pfiffer
2003-01-04  0:32   ` 2.5.54: Re: [PATCH][CFT] kexec (rewrite) for 2.5.52 Andy Pfiffer
2003-01-04 18:56     ` Eric W. Biederman
     [not found]   ` <m11y2w557p.fsf@frodo.biederman.org>
     [not found]     ` <20030204142426.A1950@in.ibm.com>
     [not found]       ` <m1d6m81ttu.fsf@frodo.biederman.org>
2003-02-06 15:56         ` [PATCH][WIP] Using kexec for crash dumps in LKCD Suparna Bhattacharya
2003-02-07 15:39           ` Suparna Bhattacharya

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=m11y3uldt9.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=andyp@osdl.org \
    --cc=haveblue@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=suparna@in.ibm.com \
    --cc=torvalds@transmeta.com \
    --cc=wa@almesberger.net \
    /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;
as well as URLs for NNTP newsgroup(s).