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, "Eric W. Biederman" <ebiederm@xmission.com>, anderson@redhat.com Subject: Re: [RFC Patch 5/6] slimdump: Capture slimdump for fatal MCE generated crashes Date: Thu, 26 May 2011 14:26:18 -0400 [thread overview] Message-ID: <20110526182618.GD29496@redhat.com> (raw) In-Reply-To: <20110526180931.GF4065@one.firstfloor.org> On Thu, May 26, 2011 at 08:09:31PM +0200, Andi Kleen wrote: > On Thu, May 26, 2011 at 01:44:47PM -0400, Vivek Goyal wrote: > > On Thu, May 26, 2011 at 10:53:05PM +0530, K.Prasad wrote: > > > > > > slimdump: Capture slimdump for fatal MCE generated crashes > > > > > > System crashes resulting from fatal hardware errors (such as MCE) don't need > > > all the contents from crashing-kernel's memory. Generate a new 'slimdump' that > > > retains only essential information while discarding the old memory. > > > > > > > Why to enforce zeroing out of rest of the vmcore data in kernel. Why not > > leave it to user space. > > I think it's a good default to not do a full dump on MCE. > It's very unlikely to be useful for anything, and will just waste > reboot time (aka nines). 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. > > That said including the dmesg too may be a good idea. dmesg is already part of vmcore and user space tools can easily find it. I can easily imagine a default policy of a distro in user space where in case of MCE crash, we just extract dmesg and MCE registers (from vmcore notes section) reboot. This will be fast and will reduce the amount of code in kernel. IMHO, we should not introduce any additional notion of slimdump as such in kernel. A better thing would be to just read MCE registers and export to user space through ELF notes and then let user space automate the rest of it. Thanks Vivek
WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com> To: Andi Kleen <andi@firstfloor.org> Cc: "Luck, Tony" <tony.luck@intel.com>, kexec@lists.infradead.org, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, anderson@redhat.com, "Eric W. Biederman" <ebiederm@xmission.com>, "K.Prasad" <prasad@linux.vnet.ibm.com> Subject: Re: [RFC Patch 5/6] slimdump: Capture slimdump for fatal MCE generated crashes Date: Thu, 26 May 2011 14:26:18 -0400 [thread overview] Message-ID: <20110526182618.GD29496@redhat.com> (raw) In-Reply-To: <20110526180931.GF4065@one.firstfloor.org> On Thu, May 26, 2011 at 08:09:31PM +0200, Andi Kleen wrote: > On Thu, May 26, 2011 at 01:44:47PM -0400, Vivek Goyal wrote: > > On Thu, May 26, 2011 at 10:53:05PM +0530, K.Prasad wrote: > > > > > > slimdump: Capture slimdump for fatal MCE generated crashes > > > > > > System crashes resulting from fatal hardware errors (such as MCE) don't need > > > all the contents from crashing-kernel's memory. Generate a new 'slimdump' that > > > retains only essential information while discarding the old memory. > > > > > > > Why to enforce zeroing out of rest of the vmcore data in kernel. Why not > > leave it to user space. > > I think it's a good default to not do a full dump on MCE. > It's very unlikely to be useful for anything, and will just waste > reboot time (aka nines). 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. > > That said including the dmesg too may be a good idea. dmesg is already part of vmcore and user space tools can easily find it. I can easily imagine a default policy of a distro in user space where in case of MCE crash, we just extract dmesg and MCE registers (from vmcore notes section) reboot. This will be fast and will reduce the amount of code in kernel. IMHO, we should not introduce any additional notion of slimdump as such in kernel. A better thing would be to just read MCE registers and export to user space through ELF notes and then let user space automate the rest of it. Thanks Vivek _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2011-05-26 18:27 UTC|newest] Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-05-26 17:07 [RFC Patch 0/6] slimdump: Enable slimdump if crashing kernel memory is not required K.Prasad 2011-05-26 17:07 ` K.Prasad 2011-05-26 17:12 ` [Patch 1/6] XPANIC: Add extended panic interface K.Prasad 2011-05-26 17:12 ` K.Prasad 2011-05-26 17:38 ` richard -rw- weinberger 2011-05-26 17:38 ` richard -rw- weinberger 2011-05-27 15:56 ` K.Prasad 2011-05-27 15:56 ` K.Prasad 2011-05-27 17:59 ` Eric W. Biederman 2011-05-27 17:59 ` Eric W. Biederman 2011-05-26 17:12 ` [Patch 2/6] x86: mce: Convert mce code to xpanic K.Prasad 2011-05-26 17:12 ` K.Prasad 2011-05-27 18:01 ` Eric W. Biederman 2011-05-27 18:01 ` Eric W. Biederman 2011-05-26 17:14 ` [Bugfix][Patch 3/3] Invoke vpanic inside xpanic function K.Prasad 2011-05-26 17:14 ` K.Prasad 2011-05-26 17:15 ` [RFC Patch 4/6] PANIC_MCE: Introduce a new panic flag for fatal MCE, capture related information K.Prasad 2011-05-26 17:15 ` K.Prasad 2011-05-26 18:43 ` Vivek Goyal 2011-05-26 18:43 ` Vivek Goyal 2011-05-27 17:03 ` K.Prasad 2011-05-27 17:03 ` K.Prasad 2011-05-27 18:29 ` Vivek Goyal 2011-05-27 18:29 ` Vivek Goyal 2011-05-27 18:04 ` Eric W. Biederman 2011-05-27 18:04 ` Eric W. Biederman 2011-05-31 17:40 ` K.Prasad 2011-05-31 17:40 ` K.Prasad 2011-06-01 17:18 ` Dave Anderson 2011-06-01 17:18 ` Dave Anderson 2011-06-01 17:23 ` Vivek Goyal 2011-06-01 17:23 ` Vivek Goyal 2011-06-01 17:41 ` Dave Anderson 2011-06-01 17:41 ` Dave Anderson 2011-06-08 17:16 ` K.Prasad 2011-06-08 17:16 ` K.Prasad 2011-06-12 15:44 ` Eric W. Biederman 2011-06-12 15:44 ` Eric W. Biederman 2011-06-15 2:06 ` K.Prasad 2011-06-15 2:06 ` K.Prasad 2011-05-27 18:09 ` Eric W. Biederman 2011-05-27 18:09 ` Eric W. Biederman 2011-05-26 17:23 ` [RFC Patch 5/6] slimdump: Capture slimdump for fatal MCE generated crashes K.Prasad 2011-05-26 17:23 ` K.Prasad 2011-05-26 17:32 ` Andi Kleen 2011-05-26 17:32 ` Andi Kleen 2011-05-27 15:53 ` K.Prasad 2011-05-27 15:53 ` K.Prasad 2011-05-26 17:44 ` Vivek Goyal 2011-05-26 17:44 ` Vivek Goyal 2011-05-26 18:09 ` Andi Kleen 2011-05-26 18:09 ` Andi Kleen 2011-05-26 18:26 ` Vivek Goyal [this message] 2011-05-26 18:26 ` Vivek Goyal 2011-05-26 18:58 ` Andi Kleen 2011-05-26 18:58 ` Andi Kleen 2011-05-26 19:10 ` Vivek Goyal 2011-05-26 19:10 ` Vivek Goyal 2011-05-26 23:44 ` Simon Horman 2011-05-26 23:44 ` Simon Horman 2011-05-27 16:57 ` K.Prasad 2011-05-27 16:57 ` K.Prasad 2011-05-27 17:59 ` Vivek Goyal 2011-05-27 17:59 ` Vivek Goyal 2011-06-08 17:00 ` K.Prasad 2011-06-08 17:00 ` K.Prasad 2011-05-27 18:14 ` Eric W. Biederman 2011-05-27 18:14 ` Eric W. Biederman 2011-05-26 17:26 ` [RFC Patch 6/6] Crash: Recognise slim coredumps and process new elf-note sections K.Prasad 2011-05-26 17:26 ` K.Prasad 2011-05-27 15:37 ` Mahesh J Salgaonkar 2011-05-27 15:37 ` Mahesh J Salgaonkar 2011-05-27 18:16 ` Eric W. Biederman 2011-05-27 18:16 ` Eric W. Biederman 2011-05-27 18:22 ` Vivek Goyal 2011-05-27 18:22 ` Vivek Goyal 2011-05-27 18:35 ` Eric W. Biederman 2011-05-27 18:35 ` Eric W. Biederman 2011-05-26 17:31 ` [RFC Patch 0/6] slimdump: Enable slimdump if crashing kernel memory is not required K.Prasad 2011-05-26 17:31 ` 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=20110526182618.GD29496@redhat.com \ --to=vgoyal@redhat.com \ --cc=anderson@redhat.com \ --cc=andi@firstfloor.org \ --cc=ebiederm@xmission.com \ --cc=kexec@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=prasad@linux.vnet.ibm.com \ --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: linkBe 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.