mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: sharada@in.ibm.com
Cc: paulus@samba.org, torvalds@osdl.org, anton@samba.org,
	linux-kernel@vger.kernel.org, miltonm@bga.com,
	fastboot@lists.osdl.org
Subject: Re: [PATCH] ppc64: kexec support for ppc64
Date: Fri, 6 May 2005 16:05:46 -0700	[thread overview]
Message-ID: <20050506160546.388aeed4.akpm@osdl.org> (raw)
In-Reply-To: <20050506124409.GB2741@in.ibm.com>

R Sharada <sharada@in.ibm.com> wrote:
>
> This patch implements the kexec support for ppc64

Well that's pretty neat.   How well does this work?

I assume you'll be working on kdump-via-kexec for ppc64?


This kdump/kexec stuff has been hanging around for far too long, IMO.  I'd
like to think about what we can do to get things moving along a bit more.

I have two issues with it:

a) Vague feelings that the low-level ia32 changes may cause APIC/etc
   breakage with some PCs.

b) Much more significantly: I still do not believe that it has been
   demonstrated that the whole kdump-via-kexec scheme will have a
   sufficiently high success rate for this to become Linux's way of doing
   crashdumps.

   And it would not be good if in six months time we decide that the
   practical problems in getting it all working sufficiently well are
   insurmountable and we have to revert it all and start working on
   something else.

   Recently I've seem a couple of "kdump worked for me" reports, which are
   greatly appreciated, but I don't think they're statistically
   significant.

   So am I right to have this concern?  If so, how can we settle this? 
   (ie: who's going to do it?  ;))


Perhaps we could declare that kexec is sufficiently useful and mature in
its own right and just merge up those bits while we work on kdump.  This
also gives us a bit of pipelining: continue to test and stabilise kexec
while kdump remains in development.

Opinions are sought...

  reply	other threads:[~2005-05-06 23:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-06  6:28 [PATCH] ppc64: global interrupt queue cleanup Paul Mackerras
2005-05-06 12:41 ` [PATCH] ppc64: native hash clear R Sharada
2005-05-06 12:44   ` [PATCH] ppc64: kexec support for ppc64 R Sharada
2005-05-06 23:05     ` Andrew Morton [this message]
2005-05-06 23:40       ` Gerrit Huizenga
2005-05-07  0:32         ` Andrew Morton
2005-05-07  2:02           ` Gerrit Huizenga
2005-05-07  2:36           ` Paul Mackerras
2005-05-07  8:40       ` [Fastboot] " Dipankar Sarma
2005-05-07 16:49       ` Suparna Bhattacharya
2005-05-09 11:55         ` Maneesh Soni
2005-05-09 12:05       ` R Sharada

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=20050506160546.388aeed4.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=anton@samba.org \
    --cc=fastboot@lists.osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miltonm@bga.com \
    --cc=paulus@samba.org \
    --cc=sharada@in.ibm.com \
    --cc=torvalds@osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome