[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5889976A.9020802@redhat.com>
Date: Thu, 26 Jan 2017 14:30:02 +0800
From: Xunlei Pang <xpang@...hat.com>
To: Borislav Petkov <bp@...en8.de>, xlpang@...hat.com
Cc: x86@...nel.org, linux-kernel@...r.kernel.org,
kexec@...ts.infradead.org, Tony Luck <tony.luck@...el.com>,
Ingo Molnar <mingo@...hat.com>, Dave Young <dyoung@...hat.com>,
Prarit Bhargava <prarit@...hat.com>,
Junichi Nomura <j-nomura@...jp.nec.com>,
Kiyoshi Ueda <k-ueda@...jp.nec.com>,
Naoya Horiguchi <n-horiguchi@...jp.nec.com>
Subject: Re: [PATCH] x86/mce: Keep quiet in case of broadcasted mce after
system panic
On 01/24/2017 at 08:22 PM, Borislav Petkov wrote:
> On Tue, Jan 24, 2017 at 09:27:45AM +0800, Xunlei Pang wrote:
>> It occurred on real hardware when testing crash dump.
>>
>> 1) SysRq-c was injected for the test in 1st kernel
>> [ 49.897279] SysRq : Trigger a crash 2) The 2nd kernel started for kdump
>> [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.10.0-229.el7.x86_64 root=UUID=976a15c8-8cbe-44ad-bb91-23f9b18e8789
> Yeah, no, I'm not debugging the RH Frankenstein kernel.
>
> Please retrigger this with latest tip/master first.
>
The hardware machine check is hard to reproduce, but the mce code of RHEL7 is quite
the same as that of tip/master, anyway we are able to inject software mce to reproduce it.
It is also clear from the theoretical analysis of the code.
Regards,
Xunlei
Powered by blists - more mailing lists