From: Hariprasad Nellitheertha <hari@in.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-kernel@vger.kernel.org, fastboot@osdl.org, akpm@osdl.org,
Suparna Bhattacharya <suparna@in.ibm.com>,
litke@us.ibm.com, mbligh@aracnet.com
Subject: Re: [Fastboot] [RFC]Kexec based crash dumping
Date: Fri, 20 Aug 2004 13:57:58 +0530 [thread overview]
Message-ID: <20040820082758.GA6560@in.ibm.com> (raw)
In-Reply-To: <m1n00q8c9p.fsf@ebiederm.dsl.xmission.com>
On Fri, Aug 20, 2004 at 02:05:54AM -0600, Eric W. Biederman wrote:
> Hariprasad Nellitheertha <hari@in.ibm.com> writes:
>
> > Hi,
> >
> > The patches that follow contain the initial implementation for kexec based
> > crash dumping that we are working on. I had sent this to the fastboot mailing
> > list a couple of weeks ago and this set of patches includes the changes made as
> > per feedback from Andrew, Eric and others.
>
> One significant change is missing. You do not separate out the two
> use cases of kexec. So on a system that is configured to use
> call sys_reboot(LINUX_REBOOT_CMD_KEXEC) on reboot I will get a core
> dump if using your code.
In some ways, whether we are doing a "crash dump" reboot or a "normal"
kexec reboot is determined by the command line parameters that are
passed to the kexec loaded kernel. If we do not restrict the memory
size and do not add the keyword "dump" in the command line, it will do
a normal kexec reboot. The dump file will not show up in the second kernel.
>
> Or alternatively if I call sys_kexec_load and then something in the
> shutdown scripts triggers a kernel panic it is not OK to
> start boot the new kernel instead of taking normal panic behavior.
A way to disable kexec reboot from panic code is indeed needed. I will
add the necessary code to do this.
>
> Until the two uses of kexec are separated they two uses
> of kexec remain mutually exclusive and incompatible, and it I cannot
> merge your patches into the existing kexec patchset.
>
> .....
>
> In general I still your kexec on panic code is doing way to much,
> and I think a lot of that is that you don't have a kernel that will
> run when loaded at a different physical address.
>
> To that end I have written a patch that accomplishes exactly that.
> Please see my just released kexec patchset.
Will work on the necessary changes so we can use your patchset.
>
> Eric
Thanks and Regards, Hari
--
Hariprasad Nellitheertha
Linux Technology Center
India Software Labs
IBM India, Bangalore
prev parent reply other threads:[~2004-08-20 8:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-17 12:04 [RFC]Kexec based crash dumping Hariprasad Nellitheertha
2004-08-17 12:05 ` [PATCH][1/6]Documentation Hariprasad Nellitheertha
2004-08-17 12:07 ` [PATCH][2/6]Memory preserving reboot using kexec Hariprasad Nellitheertha
2004-08-17 12:08 ` [PATCH][3/6]Interface for copying the dump pages Hariprasad Nellitheertha
2004-08-17 12:09 ` [PATCH][4/6]Register snapshotting before kexec-boot Hariprasad Nellitheertha
2004-08-17 12:10 ` [PATCH][5/6]ELF format interface for the dump Hariprasad Nellitheertha
2004-08-17 12:13 ` [PATCH][6/6]Device abstraction for linear/raw view of " Hariprasad Nellitheertha
2004-08-17 22:53 ` Martin J. Bligh
2004-08-18 12:29 ` Hariprasad Nellitheertha
2004-08-17 16:27 ` [PATCH][4/6]Register snapshotting before kexec-boot Dave Hansen
2004-08-18 13:43 ` Theodore Ts'o
2004-08-19 11:59 ` Hariprasad Nellitheertha
2004-08-17 16:17 ` [PATCH][3/6]Interface for copying the dump pages Dave Hansen
2004-08-17 16:01 ` [PATCH][2/6]Memory preserving reboot using kexec Dave Hansen
2004-08-17 22:44 ` [RFC]Kexec based crash dumping Andrew Morton
2004-08-18 12:28 ` Hariprasad Nellitheertha
2004-08-20 8:17 ` [Fastboot] " Eric W. Biederman
2004-08-20 8:05 ` [Fastboot] " Eric W. Biederman
2004-08-20 8:27 ` Hariprasad Nellitheertha [this message]
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=20040820082758.GA6560@in.ibm.com \
--to=hari@in.ibm.com \
--cc=akpm@osdl.org \
--cc=ebiederm@xmission.com \
--cc=fastboot@osdl.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox