Re: [PATCH v6 6/6] alpha: stop on fatal Tsunami system ECC and write parity errors

[Matt Turner]

On Mon, Oct 12, 2026 at 12:58 AM Magnus Lindholm <linmag7@xxxxxxxxx> wrote:
>
> Hi Matt,
>
> On Sun, Oct 11, 2026 at 10:01 PM Matt Turner <mattst88@xxxxxxxxx> wrote:
> >
> > > +#define TSUNAMI_PERROR_FATAL (perror_m_uecc | perror_m_perr)
> >
> > Why PERR and not RDPE? Bad parity on data read from PCI seems just as
> > bad for the consumer. If the HRM says the Pchip poisons that data and
> > the CPU takes a 670 for it, please say so in the changelog.
> >
> > > +             perror = live.perror[0] | live.perror[1];
> >
> > The changelog says incidental PERROR state on a CPU or environmental
> > vector cannot trigger the panic. It still can on a system vector: UECC
> > or PERR latched before an unrelated NXM will panic here. That may be
> > what you want, since the error is real either way, but the changelog
> > should cover it. It also depends on the PERRMASK question I asked on
> > patch 4.
> >
> > Two things that I think belong in the changelog:
> >
> > A CPU-detected uncorrectable ECC error (670 through
> > ev6_machine_check()) still does not panic, so after this patch the
> > policy differs by who detected the error.
> >
> > A PCI card with a marginal connection that asserts PERR# now takes the
> > machine down, where before it logged and carried on.
>
> Thanks, these are good points. Would it make sense to drop patch 6
> for now and address the panic policy in a follow-up? That would let
> us consider RDPE, CPU-detected ECC and previously latched errors
> alongside UECC/PERR, including the impact of a device asserting PERR#.
>
> V7 could then focus on the reporting and acknowledgment improvements.
> That would preserve the existing continuation behavior for now,
> without implying that continuing after an uncorrectable error is safe.
>
> Magnus

Yeah, that seems reasonable to me.