Re: [PATCH 2/2] EDAC/amd64: Mask UMC chip select to the four implemented selects

["Badole, Vishal" <vishal.badole@amd.com>]

On 9/28/2026 8:08 PM, Yazen Ghannam wrote:
> On Fri, Sep 25, 2026 at 11:14:29AM -0700, Borislav Petkov wrote:
>> On Fri, Sep 25, 2026 at 10:56:39PM +0530, Vishal Badole wrote:
>>> umc_get_err_info() masks the Chip Select from MCA_SYND with 0x7, a
>>> leftover from Zen 1 where the architecture reserved space for up to
>>> eight chip selects. Only four have ever been implemented, and newer
>>> products document this as MCA_SYND_UMC[1:0] = Chip Select.
>>>
>>> Since only four csrows are allocated, a syndrome with bit 2 set decodes
>>> to an out-of-range csrow and trips:
>>>
>>>    EDAC MC0: INTERNAL ERROR: csrow value is out of range (5 >= 4)
>>>
>>> Mask with 0x3 to match the four implemented chip selects.
>>>
>>> Suggested-by: Yazen Ghannam <yazen.ghannam@amd.com>
>>> Signed-off-by: Vishal Badole <Vishal.Badole@amd.com>
>>> ---
>>>   drivers/edac/amd64_edac.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
>>> index cab696be4f07..b69c3f51dd37 100644
>>> --- a/drivers/edac/amd64_edac.c
>>> +++ b/drivers/edac/amd64_edac.c
>>> @@ -2802,7 +2802,7 @@ static inline void decode_bus_error(int node_id, struct mce *m)
>>>   static void umc_get_err_info(struct mce *m, struct err_info *err)
>>>   {
>>>   	err->channel = (m->ipid & GENMASK(31, 0)) >> 20;
>>> -	err->csrow = m->synd & 0x7;
>>> +	err->csrow = m->synd & 0x3;
>>>   }
>>>   
>>>   static void decode_umc_error(int node_id, struct mce *m)
>>> -- 
>>
>> Is this ever going to change?
>>
>> Do we need to track this in the per-model struct, i.e., what your patch 1 is
>> touching?
> 
> This works for everything up through Family 1Ah.
> 
> It *could* change in the future, but I don't want to speculate.
> 
> Also, I'm working on a fresh EDAC module without all the model-specific
> stuff. This is the sort of thing it would avoid.
> 
>>
>> Is this a fix that needs to go to stable? If so, Fixes: tag and CC:stable.
>>
>> If so, patches going to stable go first and need to be minimal for ease of
>> backporting.
>>
> 
> I didn't consider this a necessary fix. But it'd be good to have it to
> avoid noise from reports.
> 
> Vishal, please do add the 'Fixes:' tag, Cc stable, and reorder the
> patches.
> 
Sure, I will update it in next patch revision.

> Otherwise, looks good.
> 
> Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>
> 
> Thanks,
> Yazen