Gitiles
Code Review Sign In
gerrit.openbmc.org / openbmc / openpower-hw-diags / adda05404a381d45762804b3a6f1f8d49c37a0c3
commitadda05404a381d45762804b3a6f1f8d49c37a0c3[log] [tgz]
authorZane Shelley <zshelle@us.ibm.com>Thu Apr 06 16:38:02 2023 -0500
committerZane Shelley <zshelle@us.ibm.com>Thu Apr 06 17:23:04 2023 -0500
treed97b95edc4cd0eaa6b09d702af630504d0424810
parent93b001c5c088d81d96a4b0c6f167f358f9a7c8f0 [diff]
Clarify definition of chip checkstop

Previously, the ATTN_TYPE_CHECKSTOP associated with a signature was
synonymous with a system checkstop event. This is certainly true for
if a processor chip checkstops. However, this is not true if a connected
OCMB chip checkstops because it is possible in some cases for a system
to recover. To differentiate an OCMB chip checkstop from a system
checkstop they were previously reported as unit checkstops. With the
addition Odyssey OCMBs, which have ability to report both chip and unit
checkstops, we decided to fix the confusion and disassociate a chip
checkstop from a system checkstop. Now the signatures will properly
report the chip attention type and the signature filtering code has been
modified to simply associate only chip checkstops from processor chips
as system checkstop attentions.

Signed-off-by: Zane Shelley <zshelle@us.ibm.com>
Change-Id: Iff9822ff8c9c0ae1afe84353010e94759dbdf49d
6 files changed
tree: d97b95edc4cd0eaa6b09d702af630504d0424810
  1. analyzer/
  2. attn/
  3. subprojects/
  4. test/
  5. util/
  6. .clang-format
  7. .eslintignore
  8. .gitignore
  9. .prettierignore
  10. .prettierrc.yaml
  11. buildinfo.hpp.in
  12. cli.cpp
  13. cli.hpp
  14. config.h.in
  15. LICENSE
  16. listener.cpp
  17. listener.hpp
  18. main.cpp
  19. main_nl.cpp
  20. meson.build
  21. meson_options.txt
  22. OWNERS
  23. README.md
README.md

Hardware Diagnostics for POWER Systems

In the event of a system fatal error reported by the internal system hardware (processor chips, memory chips, I/O chips, system memory, etc.), POWER Systems have the ability to diagnose the root cause of the failure and perform any service action needed to avoid repeated system failures.

Aditional details TBD.

Building

For a standard OpenBMC release build, you want something like:

meson -Dtests=disabled <build_dir>
ninja -C <build_dir>
ninja -C <build_dir> install

For a test / debug build, a typical configuration is:

meson -Dtests=enabled <build_dir>
ninja -C <build_dir> test