Hi,
This is interesting answer to my question so I am shearing it with you.
Tomasz
-------- Original Message -------- Subject: Re: APEI question Date: Thu, 24 Oct 2013 02:38:26 -0400 From: Chen, Gong gong.chen@linux.intel.com To: Tomasz Nowicki tn@semihalf.com
On Wed, Oct 23, 2013 at 11:16:13AM +0200, Tomasz Nowicki wrote:
Date: Wed, 23 Oct 2013 11:16:13 +0200 From: Tomasz Nowicki tn@semihalf.com To: chen gong Chen@gchen.bj.intel.com CC: gong.chen@linux.intel.com Subject: Re: APEI question User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
Let me put this in the different way.
ghes_do_proc() process errors which are reported via APEI. It handles with CPER_SEC_PLATFORM_MEM and CPER_SEC_PCIE error types. I wander why this function is not taking care of CPER_SEC_PROC_GENERIC.
Yes, the spec has covered all kinds of situations but the reality is cruel. Even FFM is enabled, not all errors can be covered by firmware. Based on the fact, only memory/IO CE and IO UC errors can be handled well by firmware by now. For processer errors, as a fact, I never saw so-called CE errors, only UC, even fatal error. As a result, you will get a MCE. You can consider that firmware just *bypass* this kind of error. In some way, that's why eMCA happens as a successor. That's all. Otherwise I will cross the red line ;-).