[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110526234401.GE2815@verge.net.au>
Date: Fri, 27 May 2011 08:44:01 +0900
From: Simon Horman <horms@...ge.net.au>
To: Vivek Goyal <vgoyal@...hat.com>
Cc: Andi Kleen <andi@...stfloor.org>,
"K.Prasad" <prasad@...ux.vnet.ibm.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"Luck, Tony" <tony.luck@...el.com>, kexec@...ts.infradead.org,
"Eric W. Biederman" <ebiederm@...ssion.com>, anderson@...hat.com
Subject: Re: [RFC Patch 5/6] slimdump: Capture slimdump for fatal MCE
generated crashes
On Thu, May 26, 2011 at 03:10:08PM -0400, Vivek Goyal wrote:
> On Thu, May 26, 2011 at 08:58:38PM +0200, Andi Kleen wrote:
> > > If we are just extracting and saving MCE registers from vmcore, then
> > > reboot time does not increase. It increases only if user decides to
> > > extract and save extra data from vmcore.
> >
> > Hmm I was thinking of user space usually saving the dump first
> > before analyzing it. But yes it could probably do some minimal
> > analysis first.
>
> In RHEL, now we filter out the dump by default until and unless user
> decides to no filter the dump with the help of config options.
>
> So I think in this case we can just introduce an extra filtering
> option in "makedumpfile" and ask it to save only MCE registers
> if it notices that there is NT_MCE type of ELF note in vmcore.
>
> I can very well imaging that extracting dmesg along with MCE registers
> can be useful. If nothing else, it can give us useful information about
> the system configuration.
>
> Zeroing out all the other ELF headers in vmcore takes away the
> capability to extract log buffers in case of MCE and I think
> it probably is not the best idea.
>
FWIW, my initial thoughts are inline with Vivek's.
I think that the bulk of this, if not all of it, can
be done in user space. And that user space is the preferable
location for such logic.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists