Searched hist:f8e750dd (Results 1 – 4 of 4) sorted by relevance
| /openbmc/phosphor-logging/extensions/openpower-pels/ |
| H A D | pel.hpp | f8e750dd Fri Jan 14 14:56:13 CST 2022 Andrew Geissler <geissonator@yahoo.com> openpower-pels: only fail on hw callouts
After further discussion with the IBM service and manufacturing team, it
was determined that firmware should only be automatically going to
Quiesce and preventing the system boot in QuiesceOnError mode when the
PEL has a hardware callout present (vs. any type of callout).
Tested:
- New unit test case
- Verified that an unrecoverable PEL with only a symbolic FRU and a
maintenance procedure callout did not trigger the Quiesce logic
- Verified that a BMC log with a HW callout still triggers the Quiesce
logic
- Verified a boot in simulation with Quiesce enabled
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I8912d59fd69b699c7da5a44da887cce4e987f6d2
|
| H A D | pel.cpp | f8e750dd Fri Jan 14 14:56:13 CST 2022 Andrew Geissler <geissonator@yahoo.com> openpower-pels: only fail on hw callouts
After further discussion with the IBM service and manufacturing team, it
was determined that firmware should only be automatically going to
Quiesce and preventing the system boot in QuiesceOnError mode when the
PEL has a hardware callout present (vs. any type of callout).
Tested:
- New unit test case
- Verified that an unrecoverable PEL with only a symbolic FRU and a
maintenance procedure callout did not trigger the Quiesce logic
- Verified that a BMC log with a HW callout still triggers the Quiesce
logic
- Verified a boot in simulation with Quiesce enabled
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I8912d59fd69b699c7da5a44da887cce4e987f6d2
|
| H A D | manager.cpp | f8e750dd Fri Jan 14 14:56:13 CST 2022 Andrew Geissler <geissonator@yahoo.com> openpower-pels: only fail on hw callouts
After further discussion with the IBM service and manufacturing team, it
was determined that firmware should only be automatically going to
Quiesce and preventing the system boot in QuiesceOnError mode when the
PEL has a hardware callout present (vs. any type of callout).
Tested:
- New unit test case
- Verified that an unrecoverable PEL with only a symbolic FRU and a
maintenance procedure callout did not trigger the Quiesce logic
- Verified that a BMC log with a HW callout still triggers the Quiesce
logic
- Verified a boot in simulation with Quiesce enabled
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I8912d59fd69b699c7da5a44da887cce4e987f6d2
|
| /openbmc/phosphor-logging/test/openpower-pels/ |
| H A D | pel_test.cpp | f8e750dd Fri Jan 14 14:56:13 CST 2022 Andrew Geissler <geissonator@yahoo.com> openpower-pels: only fail on hw callouts
After further discussion with the IBM service and manufacturing team, it
was determined that firmware should only be automatically going to
Quiesce and preventing the system boot in QuiesceOnError mode when the
PEL has a hardware callout present (vs. any type of callout).
Tested:
- New unit test case
- Verified that an unrecoverable PEL with only a symbolic FRU and a
maintenance procedure callout did not trigger the Quiesce logic
- Verified that a BMC log with a HW callout still triggers the Quiesce
logic
- Verified a boot in simulation with Quiesce enabled
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I8912d59fd69b699c7da5a44da887cce4e987f6d2
|