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

[Magnus Lindholm]

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