On Mon, 09 May 2011 22:33:36 +0530, K.Prasad wrote: > That's interesting! Assuming that these are not software induced MCEs > but panic() calls invoked due to unrecoverable memory errors in a > physical machine, did you experience any situation where the kdump > kernel hung/rebooted due to a second MCE (triggered while reading the > faulty memory location belonging to the first kernel)? Someone discussed this with me inside RH, is disabling MCE checking in the second kernel an acceptable solution? > We're contemplating a solution on the similar lines (refer the > description of 'slim' kdump at https://lkml.org/lkml/2011/5/4/396) to > create a 'crash tool readable coredump containing a message that > indicates the cause of the crash as MCE (and not any data from the old > memory). > You might want to try use other way instead of memory to store the log of the first kernel, for example, mtdoops.
