public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>,
	ebiederm@xmission.com, hbabu@us.ibm.com,
	mahesh@linux.vnet.ibm.com, oomichi@mxs.nes.nec.co.jp,
	horms@verge.net.au, heiko.carstens@de.ibm.com,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-s390@vger.kernel.org
Subject: Re: [patch 0/9] kdump: Patch series for s390 support
Date: Wed, 13 Jul 2011 16:00:04 -0400	[thread overview]
Message-ID: <20110713200004.GG4426@redhat.com> (raw)
In-Reply-To: <20110713184611.6dcb09b4@mschwide>

On Wed, Jul 13, 2011 at 06:46:11PM +0200, Martin Schwidefsky wrote:

[..]
> > What I am suggesting is that stand alone dumper gets control only if
> > kdump kernel is corrupted.
> > 
> > So following sequence.
> > 
> > Kernel Crash ---> purgatory --> either kdump kenrel/IPL stand alone tools
> > 
> > Here only drawback seems to be that we assume that purgatory code and
> > pre-calculated checksum has not been corrupted. The big advantage is
> > that s390 kdump support looks very similar to other arches and
> > understaning and supporting kdump across architectures becomes easy.
> 
> My problem with that is the following: how do we get from the "Kernel Crash"
> step to the purgatory code? It does work for "normal" panics, but it fails
> miserably for a hard crash that does not even get as far as panic. That is
> why we insist on a possible second order of things:

What is hard crash? How does that happen and what does x86 and s390
do in that case?

Though I don't have details but your argument seems to be that in s390
we are always guranteed that we will jump to IPLing the stand alone
tools code irresepective of the system state hence it is relatively
safer to do checks in stand alone tools instead of purgatory where
code is in memory.

If due to hard hang, code can not even make to purgatory, where would
it go? Can't we do IPLing of stand alone tool then. 

So we first try to take purgatory path which does the checksum and is
consistent with other architectures. If that does not work in case
of hard hang, you always have the option of IPLing the stand alone tool
later manually.

This will also get rid of requirement passing all the segment and cheksum
info to stand alone tool with the help of meminfo (That's another sore
point). 

Bottom line, even if you can't make to purgatory reliably, you always
have the option of capturing dump manually using stand alone tools. We
don't have to mix up kdump and stand alone mechanism. If kdump fails, we
just need to have capability to still capture the dump using stand alone
tools manually. I think that will make things simpler even for stand alone
tools.

Thanks
Vivek

  parent reply	other threads:[~2011-07-13 20:00 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-04 17:09 [patch 0/9] kdump: Patch series for s390 support Michael Holzheu
2011-07-04 17:09 ` [patch 1/9] kdump: Add KEXEC_CRASH_CONTROL_MEMORY_LIMIT Michael Holzheu
2011-07-04 17:09 ` [patch 2/9] kdump: Add machine_kexec_finish() Michael Holzheu
2011-07-04 17:09 ` [patch 3/9] kdump: Make kimage_load_crash_segment() weak Michael Holzheu
2011-07-04 17:09 ` [patch 4/9] kdump: Initialize vmcoreinfo note at startup Michael Holzheu
2011-07-04 17:09 ` [patch 5/9] kdump: Allow vmcore ELF header to be created in new kernel Michael Holzheu
2011-07-04 17:09 ` [patch 6/9] kdump: Merge set_vmcore_list_offsets_elf_32/64() Michael Holzheu
2011-07-04 17:09 ` [patch 7/9] kdump: Trigger kdump via panic notifier chain on s390 Michael Holzheu
2011-07-04 17:09 ` [patch 8/9] s390: kdump backend code Michael Holzheu
2011-07-04 17:09 ` [patch 9/9] kexec-tools: Add s390 kdump support Michael Holzheu
2011-07-05 20:26 ` [patch 0/9] kdump: Patch series for s390 support Vivek Goyal
2011-07-06  9:24   ` Michael Holzheu
2011-07-07 19:33     ` Vivek Goyal
2011-07-08  9:01       ` Martin Schwidefsky
2011-07-11 14:42         ` Vivek Goyal
2011-07-11 15:56           ` Martin Schwidefsky
2011-07-13 16:02             ` Vivek Goyal
2011-07-13 16:46               ` Martin Schwidefsky
2011-07-13 16:59                 ` Michael Holzheu
2011-07-13 17:19                   ` Vivek Goyal
2011-07-13 20:00                 ` Vivek Goyal [this message]
2011-07-14  7:18                   ` Martin Schwidefsky
2011-07-14 17:55                     ` Vivek Goyal
2011-07-14 18:05                       ` Vivek Goyal
2011-07-15 14:21                         ` Michael Holzheu
2011-07-15 14:38                           ` Vivek Goyal
2011-07-15 15:43                             ` Michael Holzheu
2011-07-18 12:31                               ` Vivek Goyal
2011-07-18 14:00                                 ` Michael Holzheu
2011-07-18 14:19                                   ` Vivek Goyal
2011-07-18 14:44                                     ` Michael Holzheu
2011-07-18 15:25                                       ` Vivek Goyal
2011-07-18 18:03                                         ` Michael Holzheu
2011-07-19 15:04                                           ` Vivek Goyal
2011-07-20  8:00                                             ` Martin Schwidefsky
2011-07-20  9:28                                             ` Michael Holzheu
2011-07-20 20:24                                               ` Vivek Goyal
2011-07-20 19:25                                           ` Vivek Goyal
2011-07-21 14:58                                             ` Michael Holzheu
2011-07-21 21:22                                               ` Vivek Goyal
2011-07-22  9:33                                                 ` Michael Holzheu
2011-07-25 16:02                                                   ` Vivek Goyal
2011-07-26  9:44                                                     ` Michael Holzheu
2011-07-22 15:26                                         ` Michael Holzheu
2011-07-25 18:07                                           ` Vivek Goyal
2011-07-26  9:32                                             ` Michael Holzheu
2011-07-15 13:56                       ` Michael Holzheu
2011-07-15 14:18                         ` Vivek Goyal
2011-07-18 13:57                       ` Martin Schwidefsky
2011-07-08 13:04       ` Michael Holzheu
2011-07-11 15:36         ` Vivek Goyal
2011-07-12 17:29           ` Michael Holzheu
2011-07-08 14:02       ` Michael Holzheu
2011-07-11 14:07         ` Vivek Goyal
2011-07-11 15:06           ` Michael Holzheu
2011-07-09 17:58       ` Valdis.Kletnieks
2011-07-12 13:52         ` Vivek Goyal

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=20110713200004.GG4426@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=hbabu@us.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=holzheu@linux.vnet.ibm.com \
    --cc=horms@verge.net.au \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mahesh@linux.vnet.ibm.com \
    --cc=oomichi@mxs.nes.nec.co.jp \
    --cc=schwidefsky@de.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