public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Hariprasad Nellitheertha <hari@in.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, fastboot@osdl.org,
	Suparna Bhattacharya <suparna@in.ibm.com>,
	mbligh@aracnet.com, agl@us.ibm.com
Subject: Re: [Fastboot] Re: [PATCH][2/6]Memory preserving reboot using kexec
Date: Mon, 20 Sep 2004 19:19:11 +0530	[thread overview]
Message-ID: <20040920134911.GA4592@in.ibm.com> (raw)
In-Reply-To: <m1d60i8075.fsf@ebiederm.dsl.xmission.com>

Hi Eric,

On Sun, Sep 19, 2004 at 02:37:18PM -0600, Eric W. Biederman wrote:
> Hariprasad Nellitheertha <hari@in.ibm.com> writes:
> 
> > This patch contains the code that does the memory preserving reboot. It 
> > copies over the first 640k into a backup region before handing over to 
> > kexec. The second kernel will boot using only the backup region.
> 
> Do you know what the kernel does with the low 1M?
> 
> Nothing in the hardware architecture requires us to use the
> low 1M.  So I think we would be safer if we could track down
> and remove this dependency.
> 
> In general I agree that we need to be prepared to save some of the
> original machine state, because some architectures give special
> meaning to addresses in memory.  But x86 is not one of those.
> 
> Perhaps the proper abstraction is to add a use_mem= variable
> that simply tells us which memory addresses we can use.
> 
> By still doing some copying we run into the problem, of
> potentially running out of memory areas where ongoing DMA
> transfers may be happening.  So this is worth
> tracking down.

I am trying to track this down. I tried moving the first segment of vmlinux
into the reserved section by modifying kexec-tools. This is the command line
argument segment. It still seems to need the first few kilobytes, though. 

Eliminating this is definitely needed so we can avoid using the first 
kernel's region completely.

Also, I will make the changes in the rest of the patch as per your review
comments.

Regards, Hari
-- 
Hariprasad Nellitheertha
Linux Technology Center
India Software Labs
IBM India, Bangalore

  reply	other threads:[~2004-09-20 13:49 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-15 12:50 kexec based crash dumping Hariprasad Nellitheertha
2004-09-15 12:51 ` [PATCH][1/6]Documentation Hariprasad Nellitheertha
2004-09-15 12:53   ` [PATCH][2/6]Memory preserving reboot using kexec Hariprasad Nellitheertha
2004-09-15 12:54     ` [PATCH][3/6]Routines for copying the dump pages Hariprasad Nellitheertha
2004-09-15 12:55       ` [PATCH][4/6]Register snapshotting before kexec boot Hariprasad Nellitheertha
2004-09-15 12:56         ` [PATCH][5/6]ELF format dump file access Hariprasad Nellitheertha
2004-09-15 12:57           ` [PATCH][6/6]Linear/raw " Hariprasad Nellitheertha
2004-09-15 21:28           ` [PATCH][5/6]ELF " Andrew Morton
2004-09-15 21:29           ` Andrew Morton
2004-09-15 21:31           ` Andrew Morton
2004-09-15 21:27         ` [PATCH][4/6]Register snapshotting before kexec boot Andrew Morton
2004-09-16  8:11           ` [Fastboot] " Dipankar Sarma
2004-09-17 14:53             ` Srivatsa Vaddagiri
2004-09-19 20:17               ` Eric W. Biederman
2004-09-15 21:23       ` [PATCH][3/6]Routines for copying the dump pages Andrew Morton
2004-09-15 21:22     ` [PATCH][2/6]Memory preserving reboot using kexec Andrew Morton
2004-09-19 20:37     ` [Fastboot] " Eric W. Biederman
2004-09-20 13:49       ` Hariprasad Nellitheertha [this message]
2004-09-20 19:53         ` Eric W. Biederman
2004-09-15 17:33 ` [Fastboot] kexec based crash dumping 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=20040920134911.GA4592@in.ibm.com \
    --to=hari@in.ibm.com \
    --cc=agl@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=ebiederm@xmission.com \
    --cc=fastboot@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@aracnet.com \
    --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