[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linaro-acpi
Subject:    [Linaro-acpi] Fwd: Re: APEI question
From:       Tomasz Nowicki <tomasz.nowicki () linaro ! org>
Date:       2013-10-24 7:33:19
Message-ID: 5268CD3F.9070008 () linaro ! org
[Download RAW message or body]

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 ;-).





_______________________________________________
Linaro-acpi mailing list
Linaro-acpi@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-acpi
[prev in list] [next in list] [prev in thread] [next in thread]