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, lkcd-devel@lists.sourceforge.net
Subject: Re: [PATCH][CFT] kexec (rewrite) for 2.5.52
Date: 04 Jan 2003 13:34:12 -0700 [thread overview]
Message-ID: <m1ptrck62j.fsf@frodo.biederman.org> (raw)
In-Reply-To: <20030103181100.A10924@in.ibm.com>
Suparna Bhattacharya <suparna@in.ibm.com> writes:
> On Fri, Jan 03, 2003 at 03:37:06AM -0700, Eric W. Biederman wrote:
> > 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
>
> I haven't posted this code to lkcd as yet - so far I'd only
> checked in the preparatory code reshuffle into lkcd cvs. There are
> still some things to improve and think about, but am planning
> to upgrade to the latest tree early next week and put things
> out, and then work on it incrementally.
O.k.
> > 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 missed noticing that.
> Bootimg avoided the allocation at this stage. It did something like
> this:
>
> +static unsigned long get_identity_mapped_page(void)
> +{
> + set_pgd(pgd_offset(current->active_mm,
> + virt_to_phys(unity_page)), __pgd((_KERNPG_TABLE
> + _PAGE_PSE + (virt_to_phys(unity_page)&PGDIR_MASK))));
> + return (unsigned long)unity_page;
> +}
>
> where unity page is within directly mapped memory (not highmem).
With unity_page being allocated ahead of time...
But there is some other trick it is pulling to make certain the
intermediate page table entries are present. Spooky and I don't want
to go there.
> > 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.
>
> A spare mm may be something which I could use for the crash dump
> pages mapping possibly simpler than the way it is maintained
> right now ... but haven't given enough thought to it yet.
Given that it is likely only to be a temporary thing I doubt it will
help. A very interesting question along those lines is how do
you get at all of the memory you are dumping, especially in PAE mode.
I have not seen the code that handles that part at all...
Eric
next prev parent reply other threads:[~2003-01-04 20:27 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
2003-01-03 12:41 ` Suparna Bhattacharya
2003-01-04 20:34 ` Eric W. Biederman [this message]
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=m1ptrck62j.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=andyp@osdl.org \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkcd-devel@lists.sourceforge.net \
--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).