Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1457582 > unrolled thread

Re: [Patch v3 03/11] driver/edac/mpc85xx_edac: Drop setting/clearing RFXE bit in HID1

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Patch v3 03/11] driver/edac/mpc85xx_edac: Drop setting/clearing  RFXE bit in HID1 Borislav Petkov <bp@alien8.de> - 2016-08-08 09:20 +0200
    Re: [Patch v3 03/11] driver/edac/mpc85xx_edac: Drop setting/clearing  RFXE bit in HID1 york sun <york.sun@nxp.com> - 2016-08-08 18:00 +0200
      Re: [Patch v3 03/11] driver/edac/mpc85xx_edac: Drop setting/clearing  RFXE bit in HID1 Borislav Petkov <bp@alien8.de> - 2016-08-09 05:40 +0200
        Re: [Patch v3 03/11] driver/edac/mpc85xx_edac: Drop setting/clearing  RFXE bit in HID1 Borislav Petkov <bp@alien8.de> - 2016-08-09 07:10 +0200
          Re: [Patch v3 03/11] driver/edac/mpc85xx_edac: Drop setting/clearing  RFXE bit in HID1 Borislav Petkov <bp@alien8.de> - 2016-08-09 09:00 +0200
            Re: [Patch v3 03/11] driver/edac/mpc85xx_edac: Drop setting/clearing  RFXE bit in HID1 Borislav Petkov <bp@alien8.de> - 2016-08-09 19:00 +0200
            Re: [Patch v3 03/11] driver/edac/mpc85xx_edac: Drop setting/clearing  RFXE bit in HID1 york sun <york.sun@nxp.com> - 2016-08-09 19:20 +0200
            Re: [Patch v3 03/11] driver/edac/mpc85xx_edac: Drop setting/clearing  RFXE bit in HID1 york sun <york.sun@nxp.com> - 2016-08-09 19:40 +0200
          Re: [Patch v3 03/11] driver/edac/mpc85xx_edac: Drop setting/clearing  RFXE bit in HID1 york sun <york.sun@nxp.com> - 2016-08-09 12:40 +0200
        Re: [Patch v3 03/11] driver/edac/mpc85xx_edac: Drop setting/clearing  RFXE bit in HID1 york sun <york.sun@nxp.com> - 2016-08-09 10:10 +0200

#1457582 — Re: [Patch v3 03/11] driver/edac/mpc85xx_edac: Drop setting/clearing RFXE bit in HID1

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 can also occur from
> a system error if logic on the integrated device signals a fault
> for nonfatal errors. RFXE bit is cleared out of reset, and should
> be left clear for normal operation. Assertion of core_fault_in does
> not cause a machine check.
> 
> RFXE is set specifically for RIO (Rapid IO) and PCI for book E to
> catch the errors by machine check. With this bit set, EDAC driver
> can't get the interrupt in case of uncorrectable error. So this
> bit is cleared in favor of EDAC. However, the benefit of catching
> such uncorrectable error doesn't outweight the other errors which
> may hang the system. Beside, e500v2 has different errors maksed
> by RFXE, and e500mc doesn't support this bit. It is more reasonable
> to leave RFXE as is in EDAC driver, and leave the uncorrectable
> errors triggering machine check for e500v1.

Very nice, thanks for expanding it!

Two final remarks:

- please use a spell checker

- now, what happens if you leave RFXE clear and mpc85xx_edac gets the
error? Is it going to do proper error handling of the uncorrectable
error or are we better off handling the error in the #MC interrupt
handler?

IOW, is mpc85xx_edac well equipped to handle those multibit errors or
should we leave the current setting as is?

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

[toc] | [next] | [standalone]

#1457875

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 data
>> error, such as  an L2 multibit ECC error. It can also occur from
>> a system error if logic on the integrated device signals a fault
>> for nonfatal errors. RFXE bit is cleared out of reset, and should
>> be left clear for normal operation. Assertion of core_fault_in does
>> not cause a machine check.
>>
>> RFXE is set specifically for RIO (Rapid IO) and PCI for book E to
>> catch the errors by machine check. With this bit set, EDAC driver
>> can't get the interrupt in case of uncorrectable error. So this
>> bit is cleared in favor of EDAC. However, the benefit of catching
>> such uncorrectable error doesn't outweight the other errors which
>> may hang the system. Beside, e500v2 has different errors maksed
>> by RFXE, and e500mc doesn't support this bit. It is more reasonable
>> to leave RFXE as is in EDAC driver, and leave the uncorrectable
>> errors triggering machine check for e500v1.
>
> Very nice, thanks for expanding it!
>
> Two final remarks:
>
> - please use a spell checker
>
> - now, what happens if you leave RFXE clear and mpc85xx_edac gets the
> error? Is it going to do proper error handling of the uncorrectable
> error or are we better off handling the error in the #MC interrupt
> handler?
>
> IOW, is mpc85xx_edac well equipped to handle those multibit errors or
> should we leave the current setting as is?
>

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 uncorrectable error from DDR. We will be better off to 
let this error happen.

York

[toc] | [prev] | [next] | [standalone]

#1458384

On Mon, Aug 08, 2016 at 03:39:44PM +0000, 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 uncorrectable error from DDR. We will be better off to 
> let this error happen.

So I'm reading this: "With this bit set, EDAC driver can't get the
interrupt in case of uncorrectable error. So this bit is cleared in
favor of EDAC."

AFAIU, it means, RFXE bit remains clear so EDAC will get the interrupt
for the uncorrectable error (UE). So on those !e500v1 systems, EDAC be
handling those UEs.

Am I close?

If so, can EDAC handle the UE?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

[toc] | [prev] | [next] | [standalone]

#1458403

On Tue, Aug 09, 2016 at 04:31:19AM +0000, 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
uncorrectable errors on those platforms or do they need more
sophisticated error handling in order to disable data corruption?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

[toc] | [prev] | [next] | [standalone]

#1458448

On Tue, Aug 09, 2016 at 05:06:39AM +0000, 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 with uncorrectable error.

Of course it can: it can panic the machine so that it doesn't corrupt
data on secondary storage. You might consider whether this is a better
course of action instead of only reporting the error.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

[toc] | [prev] | [next] | [standalone]

#1458969

On Tue, Aug 09, 2016 at 04:40:44PM +0000, 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 shouldn't change RXFE.
> 
> I hope I made it clear.

Yes, you did, thanks. I reread Scott's previous mail too and yes, it
doesn't make a whole lotta sense to touch the RXFE bit in EDAC. I'm
assuming firmware leaves it cleared coming out of reset so we're all
good.

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

[toc] | [prev] | [next] | [standalone]

#1459009

On 08/09/2016 08:57 AM, york.sun@nxp.com wrote:
> On 08/08/2016 11:56 PM, Borislav Petkov wrote:
>> On Tue, Aug 09, 2016 at 05:06:39AM +0000, 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 with uncorrectable error.
>>
>> Of course it can: it can panic the machine so that it doesn't corrupt
>> data on secondary storage. You might consider whether this is a better
>> course of action instead of only reporting the error.
>>
>
> Boris,
>
> My opinion is the error shouldn't happen at the first place. It usually
> means wrong configuration or physical error on the hardware. An EDAC
> driver can report these errors. How far you want to go on the error
> handling is up for discussion. I don't think we should include those
> improvement in this patch set.
>

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 shouldn't change RXFE.

I hope I made it clear.

York

[toc] | [prev] | [next] | [standalone]

#1459034

On 08/08/2016 11:56 PM, Borislav Petkov wrote:
> On Tue, Aug 09, 2016 at 05:06:39AM +0000, 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 with uncorrectable error.
>
> Of course it can: it can panic the machine so that it doesn't corrupt
> data on secondary storage. You might consider whether this is a better
> course of action instead of only reporting the error.
>

Boris,

My opinion is the error shouldn't happen at the first place. It usually 
means wrong configuration or physical error on the hardware. An EDAC 
driver can report these errors. How far you want to go on the error 
handling is up for discussion. I don't think we should include those 
improvement in this patch set.

York

[toc] | [prev] | [next] | [standalone]

#1458591

On 08/08/2016 10:01 PM, Borislav Petkov wrote:
> On Tue, Aug 09, 2016 at 04:31:19AM +0000, 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 can only report this kind of error. It is not correctable. 
Nothing more can be done.

>
> And now to get to my original question: is it *enough* to report
> uncorrectable errors on those platforms or do they need more
> sophisticated error handling in order to disable data corruption?
>

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 with uncorrectable error.

York

[toc] | [prev] | [next] | [standalone]

#1458482

On 08/08/2016 08:32 PM, Borislav Petkov wrote:
> On Mon, Aug 08, 2016 at 03:39:44PM +0000, 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 uncorrectable error from DDR. We will be better off to
>> let this error happen.
>
> So I'm reading this: "With this bit set, EDAC driver can't get the
> interrupt in case of uncorrectable error. So this bit is cleared in
> favor of EDAC."
>
> AFAIU, it means, RFXE bit remains clear so EDAC will get the interrupt
> for the uncorrectable error (UE). So on those !e500v1 systems, EDAC be
> handling those UEs.
>
> Am I close?
>
> If so, can EDAC handle the UE?
>

Yes, for most SoCs RFXE remains cleared. Uncorrectable errors are 
handled by EDAC.

York

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web