All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: hari@in.ibm.com
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, fastboot@osdl.org,
	Suparna Bhattacharya <suparna@in.ibm.com>,
	mbligh@aracnet.com, ebiederm@xmission.com, litke@us.ibm.com
Subject: Re: [Fastboot] Re: [PATCH][2/6]Memory preserving reboot using kexec
Date: 19 Sep 2004 14:37:18 -0600	[thread overview]
Message-ID: <m1d60i8075.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20040915125322.GC15450@in.ibm.com>

Hariprasad Nellitheertha <hari@in.ibm.com> writes:

> Regards, Hari
> -- 
> Hariprasad Nellitheertha
> Linux Technology Center
> India Software Labs
> IBM India, Bangalore
> 
> 
> 
> 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.

> diff -puN /dev/null include/linux/crash_dump.h
> --- /dev/null	2003-01-30 15:54:37.000000000 +0530
> +++ linux-2.6.9-rc1-hari/include/linux/crash_dump.h 2004-09-15
> 17:36:30.000000000 +0530
> 
> @@ -0,0 +1,28 @@
> +#include <linux/kexec.h>
> +#include <linux/smp_lock.h>
> +#include <linux/device.h>
> +#include <asm/crash_dump.h>
> +
> +#ifdef CONFIG_CRASH_DUMP

Why is this function an inline in a header file?
I know we only call it once but still unnecessary code
in a header file seems silly.

> +extern int crash_dump_on;
> +static inline void crash_machine_kexec(void)
> +{
> +	struct kimage *image;
> +
> +	if ((!crash_dump_on) || (crashed))
> +		return;
> +
> +	image = xchg(&kexec_image, 0);

You are still not using a different global variable here.

With a separate kexec_crash_image variable if the image is present
we do a crash dump.  That should allow you to remove the
crash_dump_on variable and the test above.

> +	if (image) {
> +		crashed = 1;
We should not need the magic global variable crashed.  We can
just call the one or two functions needed from crash_machine_kexec.

> +		device_shutdown();
Why are you calling device_shutdown here?
> +		printk(KERN_EMERG "kexec: opening parachute\n");

To wrap things prettily we should probably add a machine_crash_shutdown() 
and place in machine_crash_shutdown whatever architecture specific magic needs
to happen.

> +		machine_kexec(image);
> +		while (1);

The while look is unnecessary machine_kexec cannot
return. 

> +	} else {
> +		printk(KERN_EMERG "kexec: No kernel image loaded!\n");
> +	}
> +}
> +#else
> +#define crash_machine_kexec()	do { } while(0)
> +#endif

  parent reply	other threads:[~2004-09-19 20:39 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     ` Eric W. Biederman [this message]
2004-09-20 13:49       ` [Fastboot] " Hariprasad Nellitheertha
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=m1d60i8075.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=akpm@osdl.org \
    --cc=fastboot@osdl.org \
    --cc=hari@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=litke@us.ibm.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.