On Thu, Nov 16, 2017 at 11:00:40AM +0800, Xie XiuQi wrote:
> How about this patch?
> + /*
> + * known AO MCACODs reported via MCE or CMC:
> + *
> + * SRAO could be signaled either via a machine check exception or
> + * CMCI with the corresponding bit S 1 or 0. So we don't
On Thu, Nov 16, 2017 at 11:00:40AM +0800, Xie XiuQi wrote:
> How about this patch?
> + /*
> + * known AO MCACODs reported via MCE or CMC:
> + *
> + * SRAO could be signaled either via a machine check exception or
> + * CMCI with the corresponding bit S 1 or 0. So we don't
2001
From: Xie XiuQi <xiexi...@huawei.com>
Date: Tue, 14 Nov 2017 10:13:22 +0800
Subject: [PATCH] x86/mce: add support SRAO reported via CMC check
In Intel SDM Volume 3B (253669-063US, July 2017), SRAO could be
reported either via MCE or CMC:
In cases when SRAO is signaled via CMCI the error signature
ie XiuQi
Date: Tue, 14 Nov 2017 10:13:22 +0800
Subject: [PATCH] x86/mce: add support SRAO reported via CMC check
In Intel SDM Volume 3B (253669-063US, July 2017), SRAO could be
reported either via MCE or CMC:
In cases when SRAO is signaled via CMCI the error signature is
indicated via U
On Wed, Nov 15, 2017 at 02:44:07AM +, Luck, Tony wrote:
> This code is subtle :-(
I'm glad that we agree on this! :-)
Anyone wanting to rewrite it yet?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Wed, Nov 15, 2017 at 02:44:07AM +, Luck, Tony wrote:
> This code is subtle :-(
I'm glad that we agree on this! :-)
Anyone wanting to rewrite it yet?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
> Yes, we could just remove the check for S=1, and place "AO" entries before
> "UCNA" entries.
>
> Is that right?
Probably. But you should give more thought than I just did to the order to
make sure that we don't give the wrong classification to something because
it now matches something early in
> Yes, we could just remove the check for S=1, and place "AO" entries before
> "UCNA" entries.
>
> Is that right?
Probably. But you should give more thought than I just did to the order to
make sure that we don't give the wrong classification to something because
it now matches something early in
Hi Tony,
On 2017/11/15 10:13, Luck, Tony wrote:
>> OK, I'll add check for OVER=0 in v2.
>
> Thinking a bit more on this ... do you just need to remove the check
> for S=1 from the existing "AO" entries? Or do we need the CMCI
> match entry early in the table?
Yes, we could just remove the
Hi Tony,
On 2017/11/15 10:13, Luck, Tony wrote:
>> OK, I'll add check for OVER=0 in v2.
>
> Thinking a bit more on this ... do you just need to remove the check
> for S=1 from the existing "AO" entries? Or do we need the CMCI
> match entry early in the table?
Yes, we could just remove the
> OK, I'll add check for OVER=0 in v2.
Thinking a bit more on this ... do you just need to remove the check
for S=1 from the existing "AO" entries? Or do we need the CMCI
match entry early in the table?
-Tony
> OK, I'll add check for OVER=0 in v2.
Thinking a bit more on this ... do you just need to remove the check
for S=1 from the existing "AO" entries? Or do we need the CMCI
match entry early in the table?
-Tony
Hi Tony,
On 2017/11/15 2:51, Luck, Tony wrote:
> On Tue, Nov 14, 2017 at 01:55:11PM +0800, Xie XiuQi wrote:
>> +/* known AO MCACODs reported via CMC: */
>> +MCESEV(
>> +AO, "Action optional: memory scrubbing error",
>> +SER, MASK(MCI_UC_SAR|MCACOD_SCRUBMSK,
>>
Hi Tony,
On 2017/11/15 2:51, Luck, Tony wrote:
> On Tue, Nov 14, 2017 at 01:55:11PM +0800, Xie XiuQi wrote:
>> +/* known AO MCACODs reported via CMC: */
>> +MCESEV(
>> +AO, "Action optional: memory scrubbing error",
>> +SER, MASK(MCI_UC_SAR|MCACOD_SCRUBMSK,
>>
On Tue, Nov 14, 2017 at 01:55:11PM +0800, Xie XiuQi wrote:
> + /* known AO MCACODs reported via CMC: */
> + MCESEV(
> + AO, "Action optional: memory scrubbing error",
> + SER, MASK(MCI_UC_SAR|MCACOD_SCRUBMSK,
> MCI_STATUS_UC|MCACOD_SCRUB)
I think you should check
On Tue, Nov 14, 2017 at 01:55:11PM +0800, Xie XiuQi wrote:
> + /* known AO MCACODs reported via CMC: */
> + MCESEV(
> + AO, "Action optional: memory scrubbing error",
> + SER, MASK(MCI_UC_SAR|MCACOD_SCRUBMSK,
> MCI_STATUS_UC|MCACOD_SCRUB)
I think you should check
In Intel SDM Volume 3B (253669-063US, July 2017), SRAO could be
reported via CMC:
In cases when SRAO is signaled via CMCI the error signature is
indicated via UC=1, PCC=0, S=0.
So we add those known AO MCACODs check in mce_severity().
Signed-off-by: Xie XiuQi
In Intel SDM Volume 3B (253669-063US, July 2017), SRAO could be
reported via CMC:
In cases when SRAO is signaled via CMCI the error signature is
indicated via UC=1, PCC=0, S=0.
So we add those known AO MCACODs check in mce_severity().
Signed-off-by: Xie XiuQi
Tested-by: Chen Wei
---
18 matches
Mail list logo