All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maneesh Soni <maneesh@in.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andrew Morton <akpm@osdl.org>,
	fastboot@lists.osdl.org, haveblue@us.ibm.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Fastboot] Re: [PATCH] Fix for broken kexec on panic
Date: Thu, 24 Feb 2005 19:11:43 +0530	[thread overview]
Message-ID: <20050224134143.GC5781@in.ibm.com> (raw)
In-Reply-To: <m1wtsyrtue.fsf@ebiederm.dsl.xmission.com>

On Thu, Feb 24, 2005 at 06:05:45AM -0700, Eric W. Biederman wrote:
> Maneesh Soni <maneesh@in.ibm.com> writes:
> 
> > On Thu, Feb 24, 2005 at 01:13:12AM -0800, Andrew Morton wrote:
> > > Vivek Goyal <vgoyal@in.ibm.com> wrote:
> > > >
> > > > Kexec on panic is broken on i386 in 2.6.11-rc3-mm2 because of
> > > >  re-organization of boot memory allocator initialization code.
> > > 
> > > OK...
> > > 
> > > Where are we up to with these patches, btw?  Do you consider them
> > > close-to-complete?  Do you have a feel for what proportion of machines will
> > > work correctly?
> > 
> > After the rework of kexec patches, there is very minimal kernel code needed
> > for kdump and most of the code is in user space kexec-tools. The changes
> > needed in kexec-tools to load the crashdump kernel and generate ELF headers,
> > for x86 architecture are done and will be posted for comments today by Vivek. 
> 
> Cool.
>  
> > Currently the work remaining is to capture the old-kernel memory during second 
> > kernel boot up. There is some lack of consensus whether this functionality 
> > should go in kernel-space (/proc/vmcore) or user-space (a separate utility
> > which can be run from initrd). Before the last kexec rework, kdump has the 
> > facility to do /proc/vmcore and now it has to be re-done accordingly. There is 
> > some code already done by Eric to do it in user-space. We are evaluating both
> > the approaches and should arrive at the conclusion asap.
> 
> Do you have a pointer to your user space kdump stuff?  I have never
> seen it.

Actually I meant user space utility done by you. IMO, /proc/vmcore option 
as saves one from the hassel of a _new_ user space tool to configure / capture 
crash dumps. Though a user-space tool in addition to /proc/vmcore can be useful 
also in a badly crashed system.

> How to configure this and the usability issues are interesting.  There is
> no fundamental reason the code needs to live in a ramdisk.  We are back
> in a fully functional kernel after all.  In this case a
> ramdisk/initramfs is useful for the same reason a ramdisk with a 
> rescue disk is useful.  It is possible the normal root filesystem is
> corrupt.   A ramdisk allows you to have a known good copy of your
> tools.
> 
> Eric

-- 
Maneesh Soni
Linux Technology Center, 
IBM India Software Labs,
Bangalore, India
email: maneesh@in.ibm.com
Phone: 91-80-25044990

  reply	other threads:[~2005-02-24 13:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-24  9:13 [PATCH] Fix for broken kexec on panic Vivek Goyal
2005-02-24  9:13 ` Andrew Morton
2005-02-24 12:16   ` [Fastboot] " Maneesh Soni
2005-02-24 13:05     ` Eric W. Biederman
2005-02-24 13:41       ` Maneesh Soni [this message]
2005-02-24 12:48   ` Eric W. Biederman
2005-02-24 15:35 ` Dave Hansen

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=20050224134143.GC5781@in.ibm.com \
    --to=maneesh@in.ibm.com \
    --cc=akpm@osdl.org \
    --cc=ebiederm@xmission.com \
    --cc=fastboot@lists.osdl.org \
    --cc=haveblue@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    /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.