From: Vivek Goyal <vgoyal@redhat.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: "K.Prasad" <prasad@linux.vnet.ibm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"Luck, Tony" <tony.luck@intel.com>,
kexec@lists.infradead.org, Srivatsa Vaddagiri <vatsa@in.ibm.com>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Subject: Re: [RFC] Kdump and memory error handling
Date: Wed, 4 May 2011 23:02:56 -0400 [thread overview]
Message-ID: <20110505030256.GA11823@redhat.com> (raw)
In-Reply-To: <20110504203914.GC1737@one.firstfloor.org>
On Wed, May 04, 2011 at 10:39:14PM +0200, Andi Kleen wrote:
> > Any thoughts/suggestions?
>
> My old attempts to solve this are
>
> Don't dump on MCE:
>
> http://git.kernel.org/?p=linux/kernel/git/ak/linux-mce-2.6.git;a=shortlog;h=refs/heads/mce/xpanic
>
> Handle dumps of corrupted memory regresions:
>
> http://git.kernel.org/?p=linux/kernel/git/ak/linux-mce-2.6.git;a=shortlog;h=refs/heads/mce/crashdump
>
This idea of disabling mce temporarily sounds interesting.
The slim dump giving access to log buffers makes most sense to me. Why
not leave it to user space to filter out only log buffers. So if a
crash happens due to MCE, we can probably append an ELF note section
to vmcore and may be user space filtering utitliy (makedumpfile) can
extract and save only log portion of dump if it is an MCE triggered crash.
Of course this needs to be coupled with Andi's patch of disabling mce
temporarily so that makedumpfile does not induce another crash.
On a side note, can we just save log buf in NVRAM area and access later
using pstore (by tony luck) and if we can detect that system has that
NVRAM capability then skip kdump or something like that.
Thanks
Vivek
next prev parent reply other threads:[~2011-05-05 3:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-04 19:35 [RFC] Kdump and memory error handling K.Prasad
2011-05-04 20:02 ` Luck, Tony
2011-05-04 20:39 ` Andi Kleen
2011-05-05 3:02 ` Vivek Goyal [this message]
2011-05-05 9:25 ` Srivatsa Vaddagiri
2011-05-09 17:29 ` K.Prasad
2011-05-09 17:40 ` Vivek Goyal
2011-05-12 22:22 ` Eric W. Biederman
2011-05-17 17:24 ` 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=20110505030256.GA11823@redhat.com \
--to=vgoyal@redhat.com \
--cc=ananth@in.ibm.com \
--cc=andi@firstfloor.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=prasad@linux.vnet.ibm.com \
--cc=tony.luck@intel.com \
--cc=vatsa@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;
as well as URLs for NNTP newsgroup(s).