From: "Ken'ichi Ohmichi" <oomichi@mxs.nes.nec.co.jp>
To: vgoyal@in.ibm.com
Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
Bernhard Walle <bwalle@suse.de>, Dan Aloni <da-x@monatomic.org>,
Neil Horman <nhorman@redhat.com>
Subject: Re: Determine version of kernel that produced vmcore
Date: Wed, 18 Jul 2007 23:07:40 +0900 [thread overview]
Message-ID: <20070718230740oomichi@mail.jp.nec.com> (raw)
In-Reply-To: <20070716123633.GA10920@in.ibm.com>
Hi,
2007/07/16 18:06:33 +0530, Vivek Goyal <vgoyal@in.ibm.com> wrote:
>On Mon, Jul 16, 2007 at 02:28:54PM +0200, Bernhard Walle wrote:
>> * Vivek Goyal <vgoyal@in.ibm.com> [2007-07-16 14:25]:
>> >
>> > Ok. Now there seems to be two ways for accessing such info.
>> > - Through global variables
>> > - Export through ELF notes.
>> >
>> > Personally, I like the approach taken by Dan Aloni of exporting required
>> > info through ELF notes. That seems to be more standard in the sense we
>> > are not dependent on somebody removing above variable tomorrow.
>> >
>> > Dan, are you planning to put the modified patch for discussions on LKML?
>>
>> You mean the proposal with the makedumpfile-compatible ELF note?
>> Although I like that idea, I think Ken'ichi Ohmichi was against it.
>>
>
>Yes, makedumpfile compatible ELF note one. Ken'ichi did not like the idea
>too much, but I am not sure we discussed his objections in detail. I had
>also responded with a mail with some of the advantages of ELF note based
>approach. No response on that.
Sorry for my delayed response, I took a short vacation.
I'm not against with the proposal adding PT_NOTE segment to /proc/vmcore.
I don't like only point that adds the necessary information list
(some symbols, structures, etc.) for makedumpfile to kernel code.
The content of mkdfinfo file has been increasing whenever adding
features and correcting bugs. The content is increasing even now.
And, the feature addition is done not only for new kernels but also
for old upstream kernels. When the content of mkdfinfo file is taken
into the kernel and fixed, the feature addition in the future is
remarkably limited. So makedumpfile needs mkdfinfo file outside of
the kernel.
I propose the solution including Dan's, Vivek's and Bernhard's opinions.
How about the following sequence for distributors ?
(It is not necessary to rebuild 2nd-kernel initrd even if 1st-kernel changes.
A new option "--mkdfinfo" is added to kexec command.)
* On the kernel building system
1. Create the kernel files.
# cd linux-2.6.xx
# make
2. Create the mkdfinfo file from the vmlinux.
# makedumpfile -g mkdfinfo-2.6.xx -x vmlinux
(OSRELEASE is taken from the vmlinux.)
3. Pack the kernel package with the kernel files and the mkdfinfo file.
* On each system
4. Preload 2nd-kernel and the mkdfinfo file.
# kexec -p vmlinux-kdump --mkdfinfo=mkdfinfo-2.6.xx ...
- 2nd-kernel is preloaded.
- 1st-kernel's PAGESIZE is taken by sysconf().
- The mkdfinfo file and the above PAGESIZE is preloaded
into /proc/vmcore's PT_NOTE segment.
5. Panic happens, and the system switchs to 2nd-kernel.
6. Create a filtered dump file.
# makedumpfile -cd31 /proc/vmcore dumpfile
(User doesn't need to specify the mkdfinfo file, because the
contents of the mkdfinfo file is included into /proc/vmcore.)
Thanks
Ken'ichi Ohmichi
next prev parent reply other threads:[~2007-07-18 14:09 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-06 13:28 Determine version of kernel that produced vmcore Bernhard Walle
2007-07-06 14:58 ` Dan Aloni
2007-07-09 9:21 ` Bernhard Walle
2007-07-09 11:41 ` Dan Aloni
2007-07-09 20:49 ` Bernhard Walle
2007-07-10 4:45 ` Dan Aloni
2007-07-10 13:20 ` Bernhard Walle
2007-07-10 15:00 ` Vivek Goyal
2007-07-10 17:17 ` Neil Horman
2007-07-10 17:35 ` Dan Aloni
2007-07-10 18:26 ` Dan Aloni
2007-07-10 19:00 ` Neil Horman
2007-07-10 20:36 ` Dan Aloni
2007-07-11 11:57 ` Neil Horman
2007-07-10 6:48 ` Vivek Goyal
2007-07-10 8:14 ` Dan Aloni
2007-07-10 12:12 ` Neil Horman
2007-07-10 13:05 ` Bernhard Walle
2007-07-10 12:09 ` Neil Horman
2007-07-10 16:52 ` Dan Aloni
2007-07-11 6:07 ` Vivek Goyal
2007-07-11 7:32 ` Dan Aloni
2007-07-11 13:43 ` Ken'ichi Ohmichi
2007-07-13 3:58 ` Vivek Goyal
2007-07-13 7:49 ` Bernhard Walle
2007-07-13 3:43 ` Vivek Goyal
2007-07-11 8:58 ` Bernhard Walle
2007-07-10 3:13 ` Ken'ichi Ohmichi
2007-07-10 12:02 ` Neil Horman
2007-07-13 11:05 ` Ken'ichi Ohmichi
2007-07-13 13:15 ` Bernhard Walle
2007-07-16 4:19 ` Vivek Goyal
2007-07-16 11:57 ` Bernhard Walle
2007-07-16 12:25 ` Vivek Goyal
2007-07-16 12:27 ` Bernhard Walle
2007-07-16 12:28 ` Bernhard Walle
2007-07-16 12:36 ` Vivek Goyal
2007-07-18 14:07 ` Ken'ichi Ohmichi [this message]
2007-07-18 23:10 ` Bernhard Walle
2007-07-24 6:49 ` Ken'ichi Ohmichi
2007-07-19 14:12 ` Vivek Goyal
2007-07-19 16:39 ` Don Zickus
2007-07-19 16:49 ` Bernhard Walle
2007-07-19 16:59 ` Don Zickus
2007-07-23 5:01 ` Vivek Goyal
2007-07-23 11:47 ` Ken'ichi Ohmichi
2007-07-23 13:02 ` Dan Aloni
2007-07-23 15:58 ` Vivek Goyal
2007-07-24 6:40 ` Ken'ichi Ohmichi
2007-07-17 3:50 ` Vivek Goyal
2007-07-17 8:17 ` Bernhard Walle
2007-07-10 12:52 ` Bernhard Walle
2007-07-10 6:36 ` Vivek Goyal
2007-07-10 12:59 ` Bernhard Walle
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=20070718230740oomichi@mail.jp.nec.com \
--to=oomichi@mxs.nes.nec.co.jp \
--cc=bwalle@suse.de \
--cc=da-x@monatomic.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nhorman@redhat.com \
--cc=vgoyal@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