[PATCH v8 0/6] 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 reviewing v7 and checking the register and
frame layouts against the manuals. His Reviewed-by tags are carried on
patches 1 and 2 from v5, patch 3 from v6, and patch 4 from v7. Patches
1-3 are unchanged. The new panic policy remains deferred as agreed.

Changes since v7:
- Restrict live chipset reads, acknowledgment and live-status reporting
  to system vectors 660/620. CPU and environmental vectors leave those
  registers alone so they cannot consume a pending Pchip error.
- Correct the PERROR comment: the first error freezes the register,
  mixed error bits were detected together, and only LOST can be set
  afterwards. Remove the detached PERRMASK comment.
- Split live environmental reporting (patch 5) from console-log support
  (patch 6), so the scanner can be reviewed or deferred independently.
- Remove the environmental decoder's unused return value and print
  parameter, and keep version-history notes below the separator.
- Print console wrapper names, event/halt timestamps and halt codes.
- Replace the open-coded byte dump with print_hex_dump().
- Remove the unused console-handler registration and mark the private
  scanner helpers __init.
- Remove the unverified type-6/type-7 definitions and register annotation
  tables. Those payloads remain raw; no register ordering is assumed.

PERRMASK remains as firmware configured it. Its reset value is zero,
and the HRM says mask bits gate PERROR latching. On my ES40,
both Pchips read 0x0000000000000ff7 under the v7 console-test kernel,
and the same values were confirmed after booting v8.
DCRTO is masked; the other defined error bits are enabled. Bit 9 is also
set but is not interpreted as a defined PERROR error. These were read
through read-only /dev/mem mappings without accessing PERROR or writing
any CSR; dmesg was unchanged and kernel taint remained zero. This is an
observed runtime setting, not a measurement at reset or a claim about
other firmware configurations.

The class-5/type-4 console record observed on ES40 remains unsupported.
Patch 6 retains its firmware pointer and prints at most 1 KiB of raw
bytes per log, so it may be reported again on subsequent boots. Console
environmental payloads also remain raw because Table D-18's sys_offset
conflicts with its field offsets. Successful decoding of a nonempty
hardware console log is not claimed.

Validation:
- Native ASan/UBSan handler tests pass with CONFIG_VERBOSE_MCHECK enabled
  and disabled. Protected mock CSR pages establish that CPU and
  environmental vectors make no live chipset accesses. Tests also cover
  stale INV state, system-vector acknowledgment, malformed frames,
  environmental status, wrapper metadata and bounded console dumps.
- The six-patch mailbox applies cleanly to the stated base and reproduces
  the source tree exactly.
- Each of patches 4, 5 and 6 builds as vmlinux with W=1 and GCC 15.0.1
  for GENERIC, SHARK, DP264, EIGER and DP264 with VERBOSE_MCHECK enabled
  (15 builds). The other four configurations have it disabled. No warnings
  in touched files; logs contain unrelated kernel-doc warnings and the
  existing saved_config COMMON-symbol modpost warning. These are minimal
  configurations, not ES40 deployment builds.

V8, built with my ES40 configuration, boots on the ES40 with three CPUs
online and the root filesystem mounted read/write. Available dmesg shows
no oops, panic or new I/O/filesystem errors; kernel taint was zero during
inspection. I unplugged and reconnected one PSU. The final notification
at 926.597181 seconds reports no recognized environmental fault bits and
all three supplies enabled; all three PSU LEDs are green. SMIR bit 0
remained set, so keeping it as raw context avoids a false failure message.
This exercises reporting of a valid notification with no fault bits set.
Earlier notifications named both PSU 0 and PSU 1 despite only one supply
being disconnected; the extra indication's origin remains unexplained.

Earlier CPU, memory and file I/O stress results apply to v7, not v8.
V8's available boot log shows raw console fallback but omits the start of
scanning, so it does not independently verify firmware-pointer retention.
V8 hatch tests, ECC/PCI fault injection, successful decoding of nonempty
hardware console logs and testing on other boards remain outstanding.

Matt's v7 build report covered patches 4 and 5 for GENERIC, DP264, SHARK
and EIGER, plus DP264 without CONFIG_VERBOSE_MCHECK, with no warnings in
touched files. Those minimal configurations were not booted. His manual
review confirmed the PERROR/MISC decoding, frame layouts and Clipper bit
tables, including unconditional SERR suppression and the fact that
configuration reads do not set NDS.

Magnus Lindholm (6):
  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
  alpha: add bounded Clipper console-log scanning

 arch/alpha/include/asm/core_tsunami.h |   8 +-
 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       | 682 ++++++++++++++++++++++++++
 arch/alpha/kernel/proto.h             |   2 +
 arch/alpha/kernel/sys_dp264.c         |   3 +-
 9 files changed, 737 insertions(+), 48 deletions(-)
 create mode 100644 arch/alpha/kernel/err_tsunami.c


base-commit: 33465f6ab697abceafd9a340067a544d551c4412
-- 
2.43.0