On Tue, Feb 24, 2015 at 10:56:16AM +0100, Borislav Petkov wrote: > On Tue, Feb 24, 2015 at 08:15:35AM +0000, Naoya Horiguchi wrote: > > Let me update my explanation about the problem. I wrote the description > > about > > race window of nmi shoot down threads. That's not wrong, but that's only the > > part of the problem. The more suitable description is that all "shot down" > > CPUs keep MCE enabled (disable_local_APIC() doesn't stop it) after entering > > infinite loop of cpu_relax(), so any MCE event causes kernel panic due to > > synchronization timeout whenever after the 2nd kernel launches on the > > crashing > > CPU (where the CPU don't run do_machine_check(), but the other CPUs do). > > Ok, now we're getting closer. > > So, I'm thinking you want to disable MCA on all cores going offline > as part of the work done in crash_nmi_callback(). And off the top > of my head, it should be something what mcheck_cpu_init() and > __mcheck_cpu_init_generic() in particular does but in reverse. > > I'd even venture a guess and say that clearing CR4.MCE should be enough > but I *think* that doesn't prevent errors from being logged. Just to be > extra sure, you should clear MCG_CTL bits too. It all depends on what > exactly you want to do.
Comparing with setting tolerant to 3, clearing CR4.MCE and MCG_CTL has one benefit that we can also disable reporting to userspace. do_machine_check() calls mce_report_event() which makes the mcelog process read the log from /dev/mcelog and write it to storage even when tolerant == 3, but we can't expect that works correctly under kdump context. So keeping log data on /dev/mcelog buffer and letting them included in the crashdump looks better to me. Thanks, Naoya Horiguchi-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
