From: Dan Aloni <da-x@monatomic.org>
To: Vivek Goyal <vgoyal@in.ibm.com>
Cc: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>,
Neil Horman <nhorman@redhat.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: Determine version of kernel that produced vmcore
Date: Tue, 10 Jul 2007 11:14:14 +0300 [thread overview]
Message-ID: <20070710081413.GA29034@localdomain> (raw)
In-Reply-To: <20070710064817.GC5471@in.ibm.com>
On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
> On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
> >
>[..]
> > It contains enough information in order to make a compact kernel
> > dump (makedumpinfo needs to go over the struct page arrays). As
> > you see, it also contains the kernel version.
> >
>
> But this will not solve Bernhard's problem where looking at a vmcore
> he wants to know which vmlinux (kernel version with time stamp) has
> generated this vmcore. So adding a ELF NOTE should help.
That, or pass it in *runtime* by other means.
> > However, this file needs to be passed somehow to the rootfs
> > of the kdump kernel. This poses a chicken-and-egg problem on
> > my setup where the initramfs of the first kernel contains
> > a staticlu linked version of the kexec executable along with a
> > kdump kernel to be loaded before mount rootfs and running
> > init.
> >
>
> Why are you loading kdump kernel from first kernel's initramfs?
> I guess to enable the dump capture as soon as possible so if some
> driver panics() you can capture the dump?
Yes, that's one of the reasons.
> Can't we modify the initramfs generation process (mkinitrd) to take
> care of this situation?. By the way, how is second kernel's initramfs
> is generated currently? The moment we start packing a file which contains
> the debuginfo for first kernel, initramfs of second kernel becomes dependent
> on first kernel and to me its not a good approach.
That's not what I'm aiming for, they are actually independent (my
initramfs is a build-time constant). I have described it in another
mail.
> A dump kernel and its initrd should be independent of the crashing kernel.
I agree.
--
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Dan Aloni <da-x@monatomic.org>
To: Vivek Goyal <vgoyal@in.ibm.com>
Cc: Neil Horman <nhorman@redhat.com>,
"Ken'ichi Ohmichi" <oomichi@mxs.nes.nec.co.jp>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: Determine version of kernel that produced vmcore
Date: Tue, 10 Jul 2007 11:14:14 +0300 [thread overview]
Message-ID: <20070710081413.GA29034@localdomain> (raw)
In-Reply-To: <20070710064817.GC5471@in.ibm.com>
On Tue, Jul 10, 2007 at 12:18:17PM +0530, Vivek Goyal wrote:
> On Fri, Jul 06, 2007 at 05:58:04PM +0300, Dan Aloni wrote:
> >
>[..]
> > It contains enough information in order to make a compact kernel
> > dump (makedumpinfo needs to go over the struct page arrays). As
> > you see, it also contains the kernel version.
> >
>
> But this will not solve Bernhard's problem where looking at a vmcore
> he wants to know which vmlinux (kernel version with time stamp) has
> generated this vmcore. So adding a ELF NOTE should help.
That, or pass it in *runtime* by other means.
> > However, this file needs to be passed somehow to the rootfs
> > of the kdump kernel. This poses a chicken-and-egg problem on
> > my setup where the initramfs of the first kernel contains
> > a staticlu linked version of the kexec executable along with a
> > kdump kernel to be loaded before mount rootfs and running
> > init.
> >
>
> Why are you loading kdump kernel from first kernel's initramfs?
> I guess to enable the dump capture as soon as possible so if some
> driver panics() you can capture the dump?
Yes, that's one of the reasons.
> Can't we modify the initramfs generation process (mkinitrd) to take
> care of this situation?. By the way, how is second kernel's initramfs
> is generated currently? The moment we start packing a file which contains
> the debuginfo for first kernel, initramfs of second kernel becomes dependent
> on first kernel and to me its not a good approach.
That's not what I'm aiming for, they are actually independent (my
initramfs is a build-time constant). I have described it in another
mail.
> A dump kernel and its initrd should be independent of the crashing kernel.
I agree.
--
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il
next prev parent reply other threads:[~2007-07-10 8:14 UTC|newest]
Thread overview: 109+ 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 13:28 ` Bernhard Walle
2007-07-06 14:58 ` Dan Aloni
2007-07-06 14:58 ` Dan Aloni
2007-07-09 9:21 ` Bernhard Walle
2007-07-09 9:21 ` Bernhard Walle
2007-07-09 11:41 ` Dan Aloni
2007-07-09 11:41 ` Dan Aloni
2007-07-09 20:49 ` Bernhard Walle
2007-07-09 20:49 ` Bernhard Walle
2007-07-10 4:45 ` Dan Aloni
2007-07-10 4:45 ` Dan Aloni
2007-07-10 13:20 ` Bernhard Walle
2007-07-10 13:20 ` Bernhard Walle
2007-07-10 15:00 ` Vivek Goyal
2007-07-10 15:00 ` Vivek Goyal
2007-07-10 17:17 ` Neil Horman
2007-07-10 17:17 ` Neil Horman
2007-07-10 17:35 ` Dan Aloni
2007-07-10 17:35 ` Dan Aloni
2007-07-10 18:26 ` Dan Aloni
2007-07-10 18:26 ` Dan Aloni
2007-07-10 19:00 ` Neil Horman
2007-07-10 19:00 ` Neil Horman
2007-07-10 20:36 ` Dan Aloni
2007-07-10 20:36 ` Dan Aloni
2007-07-11 11:57 ` Neil Horman
2007-07-11 11:57 ` Neil Horman
2007-07-10 6:48 ` Vivek Goyal
2007-07-10 6:48 ` Vivek Goyal
2007-07-10 8:14 ` Dan Aloni [this message]
2007-07-10 8:14 ` Dan Aloni
2007-07-10 12:12 ` Neil Horman
2007-07-10 12:12 ` Neil Horman
2007-07-10 13:05 ` Bernhard Walle
2007-07-10 13:05 ` Bernhard Walle
2007-07-10 12:09 ` Neil Horman
2007-07-10 12:09 ` Neil Horman
2007-07-10 16:52 ` Dan Aloni
2007-07-10 16:52 ` Dan Aloni
2007-07-11 6:07 ` Vivek Goyal
2007-07-11 6:07 ` Vivek Goyal
2007-07-11 7:32 ` Dan Aloni
2007-07-11 7:32 ` Dan Aloni
2007-07-11 13:43 ` Ken'ichi Ohmichi
2007-07-11 13:43 ` Ken'ichi Ohmichi
2007-07-13 3:58 ` Vivek Goyal
2007-07-13 3:58 ` Vivek Goyal
2007-07-13 7:49 ` Bernhard Walle
2007-07-13 7:49 ` Bernhard Walle
2007-07-13 3:43 ` Vivek Goyal
2007-07-13 3:43 ` Vivek Goyal
2007-07-11 8:58 ` Bernhard Walle
2007-07-11 8:58 ` Bernhard Walle
2007-07-10 3:13 ` Ken'ichi Ohmichi
2007-07-10 3:13 ` Ken'ichi Ohmichi
2007-07-10 12:02 ` Neil Horman
2007-07-10 12:02 ` Neil Horman
2007-07-13 11:05 ` Ken'ichi Ohmichi
2007-07-13 11:05 ` Ken'ichi Ohmichi
2007-07-13 13:15 ` Bernhard Walle
2007-07-13 13:15 ` Bernhard Walle
2007-07-16 4:19 ` Vivek Goyal
2007-07-16 4:19 ` Vivek Goyal
2007-07-16 11:57 ` Bernhard Walle
2007-07-16 11:57 ` Bernhard Walle
2007-07-16 12:25 ` Vivek Goyal
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:28 ` Bernhard Walle
2007-07-16 12:36 ` Vivek Goyal
2007-07-16 12:36 ` Vivek Goyal
2007-07-18 14:07 ` Ken'ichi Ohmichi
2007-07-18 14:07 ` Ken'ichi Ohmichi
2007-07-18 23:10 ` Bernhard Walle
2007-07-18 23:10 ` Bernhard Walle
2007-07-24 6:49 ` Ken'ichi Ohmichi
2007-07-24 6:49 ` Ken'ichi Ohmichi
2007-07-19 14:12 ` Vivek Goyal
2007-07-19 14:12 ` Vivek Goyal
2007-07-19 16:39 ` Don Zickus
2007-07-19 16:39 ` Don Zickus
2007-07-19 16:49 ` Bernhard Walle
2007-07-19 16:49 ` Bernhard Walle
2007-07-19 16:59 ` Don Zickus
2007-07-19 16:59 ` Don Zickus
2007-07-23 5:01 ` Vivek Goyal
2007-07-23 5:01 ` Vivek Goyal
2007-07-23 11:47 ` Ken'ichi Ohmichi
2007-07-23 11:47 ` Ken'ichi Ohmichi
2007-07-23 13:02 ` Dan Aloni
2007-07-23 13:02 ` Dan Aloni
2007-07-23 15:58 ` Vivek Goyal
2007-07-23 15:58 ` Vivek Goyal
2007-07-24 6:40 ` Ken'ichi Ohmichi
2007-07-24 6:40 ` Ken'ichi Ohmichi
2007-07-17 3:50 ` Vivek Goyal
2007-07-17 3:50 ` Vivek Goyal
2007-07-17 8:17 ` Bernhard Walle
2007-07-17 8:17 ` Bernhard Walle
2007-07-10 12:52 ` Bernhard Walle
2007-07-10 12:52 ` Bernhard Walle
2007-07-10 6:36 ` Vivek Goyal
2007-07-10 6:36 ` Vivek Goyal
2007-07-10 12:59 ` Bernhard Walle
2007-07-10 12:59 ` Bernhard Walle
-- strict thread matches above, loose matches on Subject: below --
2007-07-23 21:08 Dave Anderson
2007-07-24 6:41 ` Ken'ichi Ohmichi
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=20070710081413.GA29034@localdomain \
--to=da-x@monatomic.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nhorman@redhat.com \
--cc=oomichi@mxs.nes.nec.co.jp \
--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 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.