From: Vivek Goyal <vgoyal@redhat.com>
To: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: ebiederm@xmission.com, mahesh@linux.vnet.ibm.com,
schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-s390@vger.kernel.org
Subject: Re: [patch 1/2] kdump: Initialize vmcoreinfo note at startup
Date: Mon, 19 Sep 2011 14:36:56 -0400 [thread overview]
Message-ID: <20110919183656.GC3373@redhat.com> (raw)
In-Reply-To: <1316161277.3507.8.camel@br98xy6r>
On Fri, Sep 16, 2011 at 10:21:17AM +0200, Michael Holzheu wrote:
> Hello Vivek,
>
> On Thu, 2011-09-15 at 14:46 -0400, Vivek Goyal wrote:
> > On Fri, Sep 09, 2011 at 12:27:00PM +0200, Michael Holzheu wrote:
> > > From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
> > >
> > > Currently the vmcoreinfo note is only initialized in case of kdump. On s390
> > > it is possible to create kernel dumps with other dump mechanisms than kdump
> > > (e.g. via hypervisor dump or stand-alone dump tools).
> >
> > Both of these will be invoked through panic notifiers because kdump kernel
> > is not loaded?
>
> This is only one possibility. The other is that they are invoked
> manually or by hypervisor watchdog without any Linux kernel involvement.
>
> >
> > >For those dumps it
> > > would also be desirable to include the vmcoreinfo data.
> >
> > Curious that how these two dump schemes make use vmcoreinfo data?
>
> We have a tool named zgetdump. With this tool it is possible to convert
> dump formats on the fly using fuse. E.g. you can mount a s390
> stand-alone dump as ELF dump. When this is done, the tool finds the
> vmcoreinfo in the stand-alone dump via our well known ABI defined
> address and it creates the respective VMCOREINFO ELF note in the output
> ELF dump. This then can be used e.g. by makedumpfile for dump filtering.
> No more need for a vmlinux file with debug information.
Ok, so you basically need it so that makedumpfile can do filtering without
debug info.
Well, if zgetdump is doing everything and you are stashing away an arch
specific pointer, I guss you could have saved pointer directly to
vmcoreinfo_data and then zgetdump could have made an ELF note out of it
for use of makedumpfile.
But anyway, having kernel exported the note does not harm.
> So this will look like the following:
>
> # zgetdump --mount standalone.dump -f elf /mnt
> # ls /mnt
> # dump.elf
> # readelf -n /mnt/dump.elf
> # ...
> VMCOREINFO 0x00000474 Unknown note type: (0x00000000)
> # makedumpfile -c -d 31 /mnt/dump.elf dump.kdump
If you can do this easily, then you really did not need kdump in kernel?
Just use stand alone dump to take dump and then do this to filter dump.
But what happens to ELF headers which map kernel virtual address to
physical addresses? kexec-tools prepares those. So in this case when
you are capturing the dump, who prepares those? IOW, how does zgetdump
creates a mapping between kernel virtual and physical addresses?
Thanks
Vivek
next prev parent reply other threads:[~2011-09-19 18:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-09 10:26 [patch 0/2] kdump: Initialize vmcoreinfo note at startup Michael Holzheu
2011-09-09 10:27 ` [patch 1/2] " Michael Holzheu
2011-09-15 18:46 ` Vivek Goyal
2011-09-16 8:21 ` Michael Holzheu
2011-09-19 18:36 ` Vivek Goyal [this message]
2011-09-20 9:04 ` Michael Holzheu
2011-09-20 13:19 ` Vivek Goyal
2011-09-09 10:27 ` [patch 2/2] s390: Export vmcoreinfo note Michael Holzheu
-- strict thread matches above, loose matches on Subject: below --
2011-09-20 14:34 [patch 0/2] kdump: Initialize vmcoreinfo note at startup Michael Holzheu
2011-09-20 14:34 ` [patch 1/2] " Michael Holzheu
2011-09-20 22:59 ` Andrew Morton
2011-09-21 8:49 ` Michael Holzheu
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=20110919183656.GC3373@redhat.com \
--to=vgoyal@redhat.com \
--cc=ebiederm@xmission.com \
--cc=heiko.carstens@de.ibm.com \
--cc=holzheu@linux.vnet.ibm.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mahesh@linux.vnet.ibm.com \
--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;
as well as URLs for NNTP newsgroup(s).