Re: [PATCH v5 5/5] alpha: decode Clipper environmental events and retain Tsunami console logs

[Magnus Lindholm]

Hi Matt,

On Sat, Oct 10, 2026 at 3:40 AM Matt Turner <mattst88@xxxxxxxxx> wrote:
>
> On Fri, Oct 9, 2026, Magnus Lindholm wrote:
> > +static const char * const CLIPPER_EnvQW5DOOR[] = {
> > + "",
> > + "Set = System CPU door is open",
> > + "Set = System Fan door is open",
> > + "Set = System PCI door is open",
>
> The "Set = " looks like it came along from the table in the manual.
> "System CPU door is open" reads better in a log.
>
Agreed, removed in v6.

> > + if (!(status & MCHK_DISPOSITION_REPORT))
> > + return MCHK_DISPOSITION_DISMISS;
>
> An event with no fault bit set is dropped, so a recovery (door closed,
> supply back) is silent unless some other fault bit is still set. If I
> read your cover letter right, the "enabled again" report in the PSU test
> was only printed because SMIR bit 0 stayed set. Is that intended? I
> think I would want to see the recovery.
>

You're right. The fault-only filter also suppressed notifications that could
describe recovery. V6 reports valid notifications even without recognized
fault bits, together with the status context.

I've booted v6 on the ES40 and repeated the PSU cable test. The individual
PSU failure indication cleared after reconnection and its enabled
indication returned.
SMIR bit 0 stayed set throughout, so this still doesn't exercise the
all-fault-bits-clear
path; that currently has synthetic coverage only.

> > +void __init
> > +tsunami_init_pci(void)
> > +{
> > + size_t i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(el_tsunami_annotations); i++)
> > + cdl_register_subpacket_annotation(&el_tsunami_annotations[i]);
> > + cdl_register_subpacket_handler(&tsunami_subpacket_handler);
> > + ev6_register_error_handlers();
> > + cdl_check_console_data_log();
> > + common_init_pci();
> > +}
>
> Two things here.
>
> cdl_check_console_data_log() follows console_data_log_pa from the HWRPB
> on every Tsunami board now, and this has run on an ES40 only. It is fine
> on QEMU's clipper, which I booted, but there the log is empty. I do not
> know what older DS10, DS20 or XP1000 firmware leaves in that field, and
> a bad pointer would mean a crash during boot. Can anyone on the list try
> it on one of those?
>
> It is also odd to have the PCI init hook in the error file. Titan has
> titan_register_error_handlers() in err_titan.c and leaves the init_pci
> hook in sys_titan.c, which calls cdl_check_console_data_log() itself.
> The same split would work here.
>
Agreed. V6 follows the Titan split: error-handler registration stays in the
error file, with PCI initialization and the console-log call in sys_dp264.c.

> The table sizes all match their masks, and the subpacket length checks
> look right to me.

Thanks for the feedback

Magnus