Re: spurious mce Hardware Error messages in next-20250912

[Nikolay Borisov]

On 9/17/25 22:26, Yazen Ghannam wrote:
<snip>


> Right, so it seems we have bogus data logged in these registers. And
> this is unrelated to the recent patches.
>
> We have some combination of bits set in MCA_DESTAT registers. The
> deferred error interrupt hasn't fired (at least from the latest
> example).
>
> There does seem to be some combination of bits that are always set and
> others flip between examples.
>
> I'll highlight this to our hardware folks. But I don't think there's
> much we can do other than filter these out somehow.
>
> I can add two checks to the patch to make it more like the current
> behavior.
>
> 1) Check for 'Deferred' status bit when logging from the MCA_DESTAT.
> This was in the debug patch I shared.

According to AMD APM 9.3.3.4:

"If the error being logged is a deferred error, then the error will be 
logged to MCA_DESTAT."

So this means that when Valid is set in DESTAT then the error MUST BE 
deferred. I.e I think it's in valid to have valid && !deferred in 
DESTAT, no ?

Additionally nowhere in the APM is ti mentioned what's the default value 
of MCA_CONFIG.LogDeferredEn so as it stands you are now working with the 
assumption that it's 1 and DESTAT is always a redundant copy of STATUS.

Btw looking at the output that Bert has provided it seems that indeed 
MCA_CONFIG.LogDeferredEn is 0 by default:

"
LogDeferredEn—Bit 34. Enable logging of deferred errors in MCA_STATUS. 
0=Log deferred errors only in MCA_DESTAT and MCA_DEADDR. 1=Log deferred 
errors in MCA_STATUS and MCA_ADDR in addition to MCA_DESTAT and 
MCA_DEADDR. This bit does not affect logging of deferred errors in 
MCA_SYND or MCA_MISCx.
"


I think the polling code is slightly broken now for AMD. The order of 
operation per poll cycle should be:

1. Check MCA_STATUS -> report if there is anything, clear it the bank
2. (In the same cycle) -> Check DEFERRED and report if there is 
anything, clear the deferred.


> 2) Only check MCA_DESTAT when we are notified by the deferred error
> interrupt.
>
> Technically, both of these shouldn't be necessary based on the
> architecture.
>
> So there's a third option: add this error signature to our filter_mce()
> function.
> > As I write this out, I feel more inclined to option #3. I think it 
would
> be better to stick to the architecture. We may get error reports like
> this. But that may be preferable so that any potential hardware issues
> can be investigated sooner. If there's a real problem, better to get it
> fixed in future products rather than implicitly mask it by our code
> flow.
>
> Any thoughts from others?
>
> Thanks,
> Yazen