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

[Badole, Vishal]

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@xxxxxxx>
> > > Signed-off-by: Vishal Badole <Vishal.Badole@xxxxxxx>
> > > ---
> > >   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@xxxxxxx>
>
> Thanks,
> Yazen