On 08/08/2016 11:56 PM, Borislav Petkov wrote:
> On Tue, Aug 09, 2016 at 05:06:39AM +, york sun wrote:
>> It is uncorrectable. DDR controller can only report the error. I don't
>> believe EDAC driver can do more. For the same reason I said we can leave
>> RXFE as is, even for e500v1 case (with
On 08/08/2016 11:56 PM, Borislav Petkov wrote:
> On Tue, Aug 09, 2016 at 05:06:39AM +, york sun wrote:
>> It is uncorrectable. DDR controller can only report the error. I don't
>> believe EDAC driver can do more. For the same reason I said we can leave
>> RXFE as is, even for e500v1 case (with
On 08/09/2016 08:57 AM, york@nxp.com wrote:
> On 08/08/2016 11:56 PM, Borislav Petkov wrote:
>> On Tue, Aug 09, 2016 at 05:06:39AM +, york sun wrote:
>>> It is uncorrectable. DDR controller can only report the error. I don't
>>> believe EDAC driver can do more. For the same reason I said
On 08/09/2016 08:57 AM, york@nxp.com wrote:
> On 08/08/2016 11:56 PM, Borislav Petkov wrote:
>> On Tue, Aug 09, 2016 at 05:06:39AM +, york sun wrote:
>>> It is uncorrectable. DDR controller can only report the error. I don't
>>> believe EDAC driver can do more. For the same reason I said
On Tue, Aug 09, 2016 at 04:40:44PM +, york sun wrote:
> I want to add this, normally uncorrectable errors don't trigger machine
> check on e500v1. RXFE controls different interrupt on e500v2. e500mc
> doesn't support RXFE. Together with the reason I explained, I believe
> EDAC driver
On Tue, Aug 09, 2016 at 04:40:44PM +, york sun wrote:
> I want to add this, normally uncorrectable errors don't trigger machine
> check on e500v1. RXFE controls different interrupt on e500v2. e500mc
> doesn't support RXFE. Together with the reason I explained, I believe
> EDAC driver
On 08/08/2016 10:01 PM, Borislav Petkov wrote:
> On Tue, Aug 09, 2016 at 04:31:19AM +, york sun wrote:
>> Yes, for most SoCs RFXE remains cleared. Uncorrectable errors are
>> handled by EDAC.
>
> And how is mpc85_xxx EDAC handling them?
>
> mpc85xx_mc_check() only reports them.
Correct. It
On 08/08/2016 10:01 PM, Borislav Petkov wrote:
> On Tue, Aug 09, 2016 at 04:31:19AM +, york sun wrote:
>> Yes, for most SoCs RFXE remains cleared. Uncorrectable errors are
>> handled by EDAC.
>
> And how is mpc85_xxx EDAC handling them?
>
> mpc85xx_mc_check() only reports them.
Correct. It
On 08/08/2016 08:32 PM, Borislav Petkov wrote:
> On Mon, Aug 08, 2016 at 03:39:44PM +, york sun wrote:
>> RFXE is cleared by default. So for most SoCs, this is not even a concern
>> at all. But for e500v1, when RIO or PCI are used, this bit is set
>> specifically to catch an error by machine
On 08/08/2016 08:32 PM, Borislav Petkov wrote:
> On Mon, Aug 08, 2016 at 03:39:44PM +, york sun wrote:
>> RFXE is cleared by default. So for most SoCs, this is not even a concern
>> at all. But for e500v1, when RIO or PCI are used, this bit is set
>> specifically to catch an error by machine
On Tue, Aug 09, 2016 at 05:06:39AM +, york sun wrote:
> It is uncorrectable. DDR controller can only report the error. I don't
> believe EDAC driver can do more. For the same reason I said we can leave
> RXFE as is, even for e500v1 case (with RIO or PCI is enabled). Nothing
> can be done
On Tue, Aug 09, 2016 at 05:06:39AM +, york sun wrote:
> It is uncorrectable. DDR controller can only report the error. I don't
> believe EDAC driver can do more. For the same reason I said we can leave
> RXFE as is, even for e500v1 case (with RIO or PCI is enabled). Nothing
> can be done
On Tue, Aug 09, 2016 at 04:31:19AM +, york sun wrote:
> Yes, for most SoCs RFXE remains cleared. Uncorrectable errors are
> handled by EDAC.
And how is mpc85_xxx EDAC handling them?
mpc85xx_mc_check() only reports them.
And now to get to my original question: is it *enough* to report
On Tue, Aug 09, 2016 at 04:31:19AM +, york sun wrote:
> Yes, for most SoCs RFXE remains cleared. Uncorrectable errors are
> handled by EDAC.
And how is mpc85_xxx EDAC handling them?
mpc85xx_mc_check() only reports them.
And now to get to my original question: is it *enough* to report
On Mon, Aug 08, 2016 at 03:39:44PM +, york sun wrote:
> RFXE is cleared by default. So for most SoCs, this is not even a concern
> at all. But for e500v1, when RIO or PCI are used, this bit is set
> specifically to catch an error by machine check (see commit 4e0e3435).
> This is not the
On Mon, Aug 08, 2016 at 03:39:44PM +, york sun wrote:
> RFXE is cleared by default. So for most SoCs, this is not even a concern
> at all. But for e500v1, when RIO or PCI are used, this bit is set
> specifically to catch an error by machine check (see commit 4e0e3435).
> This is not the
On 08/08/2016 12:11 AM, Borislav Petkov wrote:
> On Thu, Aug 04, 2016 at 03:58:28PM -0700, York Sun wrote:
>> On e500v1, read fault exception enable (RFXE) controls whether
>> assertion of core_fault_in causes a machine check interrupt.
>> Assertion of core_fault_in can result from uncorrectable
On 08/08/2016 12:11 AM, Borislav Petkov wrote:
> On Thu, Aug 04, 2016 at 03:58:28PM -0700, York Sun wrote:
>> On e500v1, read fault exception enable (RFXE) controls whether
>> assertion of core_fault_in causes a machine check interrupt.
>> Assertion of core_fault_in can result from uncorrectable
On Thu, Aug 04, 2016 at 03:58:28PM -0700, York Sun wrote:
> On e500v1, read fault exception enable (RFXE) controls whether
> assertion of core_fault_in causes a machine check interrupt.
> Assertion of core_fault_in can result from uncorrectable data
> error, such as an L2 multibit ECC error. It
On Thu, Aug 04, 2016 at 03:58:28PM -0700, York Sun wrote:
> On e500v1, read fault exception enable (RFXE) controls whether
> assertion of core_fault_in causes a machine check interrupt.
> Assertion of core_fault_in can result from uncorrectable data
> error, such as an L2 multibit ECC error. It
On e500v1, read fault exception enable (RFXE) controls whether
assertion of core_fault_in causes a machine check interrupt.
Assertion of core_fault_in can result from uncorrectable data
error, such as an L2 multibit ECC error. It can also occur from
a system error if logic on the integrated
On e500v1, read fault exception enable (RFXE) controls whether
assertion of core_fault_in causes a machine check interrupt.
Assertion of core_fault_in can result from uncorrectable data
error, such as an L2 multibit ECC error. It can also occur from
a system error if logic on the integrated
22 matches
Mail list logo
