Messages in this thread | | | Date | Wed, 23 Nov 2011 23:03:18 +0530 | From | "K.Prasad" <> | Subject | Re: [RFC Patch 0/2] Slimdump framework using CRASH_REASON - v2 |
| |
On Mon, Nov 21, 2011 at 10:17:27AM -0500, Vivek Goyal wrote: > On Mon, Nov 21, 2011 at 03:24:05PM +0530, K.Prasad wrote: > > Hi All, > > In furtherance of the previous discussion regarding 'slimdump' > > (refer: http://article.gmane.org/gmane.linux.kernel/1204967), it was > > decided that, > > > > - An entry in VMCOREINFO elf-note be added to denote the cause of crash, > > instead of creating a new elf-note. > > > > - Upstream tools such as 'makedumpfile' and 'crash' be modified to > > recognise this string and inform the user accordingly. > > > > Accordingly, this new version of the patchset makes the following > > changes > > > > Changelog - version 2 > > ----------------------- > > (First version posted here: > > http://article.gmane.org/gmane.linux.kernel/1198435) > > > > - Append VMCOREINFO elf-note with a new variable CRASH_REASON whose > > value will be populated using arch_add_crash_reason() function. > > > > - Define arch_add_crash_reason() in the x86 MCE path to return "PANIC_MCE" > > in the panic path of MCE. > > > > - 'makedumpfile' tool is taught to recognise PANIC_MCE string as one > > value of CRASH_REASON for which 'slimdump' must be captured. > > So again, what is slimdump? I mean, what information is now being captured > in the case of slimdump? Are you capturing atleast the kernel message > buffers? I am assuming that any register info emitted on console will > make into kernel buffers and that should be useful to figure out what > MCE happened. >
The kernel message buffers can be obtained by using the --dump-dmesg option of makedumpfile but again that's risky. We wouldn't know if it'll cause access to the faulty memory (which is how the previous method of having a new elf-notes in a pristine location is much safer).
The method in this patch is quite primitive in that informs the user nothing more than a one-line cause of crash. One should take help from other tools (such as service processor/firmware/ACPI logs, or previous corrected error logs) to infer the location of bad memory. It would have been helpful if we could provide a dump of related information such as contents of "struct mce" (like in the very first iteration of the patch, refer: http://article.gmane.org/gmane.linux.kernel/1146215), but that would need some memory (possibly in the form of a new elf-note).
Thanks, K.Prasad
| |