[PATCH v7 0/5] alpha: improve Tsunami machine check reporting

[Magnus Lindholm <linmag7@gmail.com>]

This series adds Tsunami/Typhoon system-error diagnostics and Clipper
ES40 environmental reporting. It applies to v7.3-rc1 on Alpha for-next
at 33465f6ab697.

Thanks to Matt Turner for the v6 review. His Reviewed-by tags are carried
on patches 1 and 2 from v5 and patch 3 from v6. Patches 1-3 have no code
changes since v6.

Changes since v6:
- Drop v6 patch 6, "alpha: stop on fatal Tsunami system ECC and write
  parity errors", as agreed with Matt. The panic policy will be handled
  separately; v7 focuses on reporting and acknowledgment improvements
  without adding a new panic path.
- Remove the duplicate irq_regs.h include and the trailing blank line.
- Gate full register dumps for correctable system errors on verbose
  machine-check reporting; retain their error decode and always show
  registers for uncorrectable system errors.
- Document that PERRMASK gates new PERROR latching (HRM 10.2.5.7), and
  that the ECC field selection does not establish mixed-error ordering.
- Retain conservative SERR transaction suppression: HRM 8.8.2.6 leaves
  address/command undefined whenever SERR is set, with no stated exception
  for combined errors. This differs from the suggested SERR-only check.
- Remove the redundant environmental silent pass and always-true condition.
- Treat SMIR bit 0 as raw context, using fault mask 0x14. It stayed set
  after PSU reconnection on the ES40, so do not label it a current failure.
- Print the recorded CPU ID for processor console subpackets.
- Bound Clipper console-log traversal by the HWRPB byte count. Preserve
  the firmware pointer on unknown or truncated records and dump at most
  1 KiB of raw data. Acknowledge only after a complete termination packet;
  no class-5/type-4 layout is assumed.

Deferring panic policy preserves the existing continuation behavior; it
is not a claim that continuing is safe after an uncorrectable error.
Acknowledging a latch does not repair corrupted data. A follow-up needs
to consider CPU-detected ECC, Pchip UECC, RDPE/PERR, previously latched
errors, firmware masks and the impact of a device asserting PERR#.
In particular, HRM 8.8.2.3 says erroneous PIO read data is returned as
received; it does not establish an automatic CPU 670 for that case.

PERRMASK is left as firmware configured it. A zero mask bit prevents new
latching but does not establish that previously latched status is cleared.
SMIR polarity/latching, inverted halt/reset bits, other-board firmware
layouts and successful nonempty console-log decoding remain unverified.
Console-log scanning remains restricted to Clipper; ambiguous console
environmental records remain raw.

Testing:
- Native ASan/UBSan tests pass with CONFIG_VERBOSE_MCHECK enabled and
  disabled, including runtime verbosity selection, SERR with other bits,
  mixed ECC/PCI decoding, processor subpacket CPU IDs and the new SMIR mask.
- The observed v6 PSU state sequence was replayed synthetically: individual
  failure reports remain visible and the final state reports no recognized
  fault bits while preserving raw SMIR=1. This is not a v7 hardware test.
- V7 tip vmlinux builds pass with W=1 and GCC 15.0.1 for GENERIC,
  DP264, SHARK and EIGER using minimal configurations. No warnings in
  touched files; logs contain unrelated kernel-doc warnings and the
  saved_config COMMON-symbol modpost warning. These are not per-patch
  or ES40 deployment builds.

V6 was boot-tested on my ES40 with GENERIC_ENTRY enabled. Unplugging and
reconnecting PSU AC power produced code 206 notifications: PSU 1's
individual failure indication cleared and its enabled indication returned,
while SMIR bit 0 remained set in all three reports.

V7 was built and boot-tested on my AlphaServer ES40. Basic CPU, memory
and file I/O checks passed with no new kernel messages or kernel taint.

Matt built all six v6 patches for GENERIC, DP264, SHARK and EIGER with
W=1 and GCC 16.2.0 (24 builds), with no warnings in touched files, and
booted its GENERIC tip on QEMU Clipper to root mounting. These results
apply to v6; they do not establish machine-check or manual-layout coverage.

Magnus Lindholm (5):
  alpha: move Tsunami machine check handling to err_tsunami.c
  alpha: describe the Tsunami system machine check frame
  alpha: bound EV6 logout decoding by the processor area
  alpha: decode and acknowledge Tsunami system machine checks
  alpha: decode Clipper environmental events and retain console logs

 arch/alpha/include/asm/core_tsunami.h |   8 +-
 arch/alpha/include/asm/err_common.h   |   2 +
 arch/alpha/kernel/Makefile            |   4 +-
 arch/alpha/kernel/core_tsunami.c      |  34 --
 arch/alpha/kernel/err_common.c        |  13 +
 arch/alpha/kernel/err_ev6.c           |  38 +-
 arch/alpha/kernel/err_impl.h          |   1 +
 arch/alpha/kernel/err_tsunami.c       | 724 ++++++++++++++++++++++++++
 arch/alpha/kernel/proto.h             |   3 +
 arch/alpha/kernel/sys_dp264.c         |   5 +-
 10 files changed, 784 insertions(+), 48 deletions(-)
 create mode 100644 arch/alpha/kernel/err_tsunami.c


base-commit: 33465f6ab697abceafd9a340067a544d551c4412
-- 
2.43.0