From: Vivek Goyal <vgoyal@redhat.com>
To: "K.Prasad" <prasad@linux.vnet.ibm.com>
Cc: Dave Anderson <anderson@redhat.com>,
Borislav Petkov <bp@alien8.de>, Tony Luck <tony.luck@intel.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
tachibana@mxm.nes.nec.co.jp, oomichi@mxs.nes.nec.co.jp,
Valdis Kletnieks <Valdis.Kletnieks@vt.edu>,
Nick Bowler <nbowler@elliptictech.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC Patch 1/2][slimdump] Append CRASH_REASON to VMCOREINFO elf-note
Date: Mon, 28 Nov 2011 09:26:52 -0500 [thread overview]
Message-ID: <20111128142652.GB20758@redhat.com> (raw)
In-Reply-To: <20111123173930.GC2515@in.ibm.com>
On Wed, Nov 23, 2011 at 11:09:31PM +0530, K.Prasad wrote:
> On Mon, Nov 21, 2011 at 10:19:31AM -0500, Dave Anderson wrote:
> >
> >
> > ----- Original Message -----
> > > Allow various crash paths to append the reason of crash into the
> > > VMCOREINFO elf-note through the field CRASH_REASON. We also make the
> > > fatal machine check exceptions append "PANIC_MCE" as the crash
> > > reason. This string will be recognised by upstream tools like makedumpfile and
> > > crash to generate slimdump.
> >
> > I don't understand -- how could "various paths" append a reason?
> > The patch below seems to return "PANIC_MCE" for every x86 crash.
> > What am I missing?
> >
> > Dave
> >
>
> Yes, presently it can only be "PANIC_MCE" for MCE crashes in x86 (not
> for every crash though).
>
> With increased usage, we should move this code to a generic location and
> let each of these crash paths return a string to be appended. In fact it
> doesn't have to be a string for CRASH_REASON but just an encoding of the
> various crash types into numbers. User-space tools could then do a lookup
> for getting the right crash string.
Probably string is a better idea? Where do we do lookup to find out what
maps to what? This would require kernel exporting this info in a header
and then comes the issue of having same kernel version info. Or the issue
of analyzing kernel dumps on the same machine.
Storing a string will atleast help that one does not have to worry about
mapping error code. makedumpfile shall have to grep for exact same string
though.
Thanks
Vivek
next prev parent reply other threads:[~2011-11-28 14:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-21 9:54 [RFC Patch 0/2] Slimdump framework using CRASH_REASON - v2 K.Prasad
2011-11-21 10:11 ` [RFC Patch 1/2][slimdump] Append CRASH_REASON to VMCOREINFO elf-note K.Prasad
2011-11-21 15:11 ` Vivek Goyal
2011-11-23 16:14 ` K.Prasad
2011-11-21 15:19 ` Dave Anderson
2011-11-23 17:39 ` K.Prasad
2011-11-28 14:26 ` Vivek Goyal [this message]
2011-11-23 17:42 ` K.Prasad
2011-11-23 19:45 ` Dave Anderson
2011-11-29 14:37 ` K.Prasad
2011-11-21 10:14 ` [RFC Patch 2/2][slimdump][makedumpfile] Recognise PANIC_MCE crashes to generate slimdu K.Prasad
2011-11-21 15:17 ` [RFC Patch 0/2] Slimdump framework using CRASH_REASON - v2 Vivek Goyal
2011-11-23 17:33 ` K.Prasad
2011-11-28 14:24 ` Vivek Goyal
2011-11-30 17:15 ` K.Prasad
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=20111128142652.GB20758@redhat.com \
--to=vgoyal@redhat.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=anderson@redhat.com \
--cc=bp@alien8.de \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nbowler@elliptictech.com \
--cc=oomichi@mxs.nes.nec.co.jp \
--cc=prasad@linux.vnet.ibm.com \
--cc=tachibana@mxm.nes.nec.co.jp \
--cc=tony.luck@intel.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