PEL: Fix markdownlint errors in reg/README.md
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ia1d51f87ec4e032accc15e8f659fdb00f7961e0d
diff --git a/extensions/openpower-pels/registry/README.md b/extensions/openpower-pels/registry/README.md
index 0385ad4..69ff800 100644
--- a/extensions/openpower-pels/registry/README.md
+++ b/extensions/openpower-pels/registry/README.md
@@ -47,7 +47,7 @@
This is the key into the message registry, and is the Message property of the
OpenBMC event log that the PEL is being created from.
-```
+```json
"Name": "xyz.openbmc_project.Power.Fault"
```
@@ -59,7 +59,7 @@
the time of PEL creation using the 'PEL_SUBSYSTEM' AdditionalData field. In this
case, 'Subsystem' isn't required, though 'PossibleSubsystems' is.
-```
+```json
"Subsystem": "power_supply"
```
@@ -70,7 +70,7 @@
using the 'Subsystem' field. It is mutually exclusive with the 'Subsystem'
field.
-```
+```json
"PossibleSubsystems": ["memory", "processor"]
```
@@ -84,11 +84,11 @@
are based on system type, where an entry without a system type will match
anything unless another entry has a matching system type.
-```
+```json
"Severity": "unrecoverable"
```
-```
+```json
Severity":
[
{
@@ -110,7 +110,7 @@
specific manufacturing isolation mode is enabled. It has the same format as
Severity.
-```
+```json
"MfgSeverity": "unrecoverable"
```
@@ -120,7 +120,7 @@
event scope, as defined by the PEL spec. It is optional and defaults to "entire
platform".
-```
+```json
"EventScope": "entire_platform"
```
@@ -131,7 +131,7 @@
applicable" for non-informational logs, and "misc_information_only" for
informational ones.
-```
+```json
"EventType": "na"
```
@@ -148,7 +148,7 @@
are correct. The rules used for this are
[here](../README.md#action-flags-and-event-type-rules).
-```
+```json
"ActionFlags": ["service_action", "report", "call_home"]
```
@@ -157,7 +157,7 @@
This is an optional field and is used to override the Action Flags field when a
specific manufacturing isolation mode is enabled.
-```
+```json
"MfgActionFlags": ["service_action", "report", "call_home"]
```
@@ -168,7 +168,7 @@
upper byte of the reason code. If present for `BD` SRCs, then this byte must
match the upper byte of the reason code.
-```
+```json
"ComponentID": "0x5500"
```
@@ -187,7 +187,7 @@
For `11` SRCs, it looks like: `1100RRRR`, where RRRR is the SRC reason code.
-```
+```json
"Type": "11"
```
@@ -198,7 +198,7 @@
the same as the first byte of the component ID field in the Private Header
section that represents the creator's component ID.
-```
+```json
"ReasonCode": "0x5544"
```
@@ -215,7 +215,7 @@
`<ASCII_STRING>_<SRCWord3>_<SRCWord9>`, which could look like:
`B181320_00000050_49000000`.
-```
+```json
"SymptomIDFields": ["SRCWord3", "SRCWord9"]
```
@@ -228,7 +228,7 @@
define what the SRC word means for use by parsers. If not specified, these SRC
words will be set to zero in the PEL.
-```
+```json
"Words6to9":
{
"6":
@@ -254,7 +254,7 @@
`MessageArgSources` property must be present to say which SRC words to use for
each placeholder.
-```
+```json
"Message": "Processor %1 had %2 errors"
```
@@ -265,7 +265,7 @@
placeholders from. In the example below, SRC word 6 would be used for %1, and
SRC word 7 for %2.
-```
+```json
"MessageArgSources":
[
"SRCWord6", "SRCWord7"
@@ -277,7 +277,7 @@
A short description of the error. This is required by the Redfish schema to
generate a Redfish message entry, but is not used in Redfish or PEL output.
-```
+```json
"Description": "A power fault"
```
@@ -287,7 +287,7 @@
registry entry, as comments are not allowed in JSON. It is an array of strings
for easier readability of long fields.
-```
+```json
"Notes": [
"This entry is for every type of power fault.",
"There is probably a hardware failure."
@@ -308,7 +308,7 @@
#### Callouts example based on the system type
-```
+```json
"Callouts":
[
{
@@ -345,7 +345,7 @@
#### Callouts example based on an AdditionalData field
-```
+```json
"CalloutsUsingAD":
{
"ADName": "PROC_NUM",
@@ -396,7 +396,7 @@
example, the 'air_mover' callout will be added if 'PROC_NUM' isn't 0.
'CalloutsWhenNoADMatch' has the same schema as the 'Callouts' section.
-```
+```json
"CalloutsUsingAD":
{
"ADName": "PROC_NUM",
@@ -437,7 +437,7 @@
This field can be used to modify the failing component type field in the callout
when the default doesn\'t fit:
-```
+```json
{
"Priority": "high",
@@ -466,12 +466,11 @@
callout with that inventory item will not be created. The symbolic FRU must be
the first callout in the registry for this to work.
-```
+```json
{
-
- "Priority": "high",
- "SymbolicFRUTrusted": "AIR_MOVR",
- "UseInventoryLocCode": true
+ "Priority": "high",
+ "SymbolicFRUTrusted": "AIR_MOVR",
+ "UseInventoryLocCode": true
}
```
@@ -488,23 +487,24 @@
the schema validation. This script is also run to validate the message
registry as part of CI testing.
-```
- ./tools/process_registry.py -v -s schema/schema.json -r message_registry.json
-```
+ ```sh
+ ./tools/process_registry.py -v -s schema/schema.json -r message_registry.json
+ ```
4. One can test what PELs are generated from these new entries without writing
any code to create the corresponding event logs:
+
1. Copy the modified message_registry.json into `/etc/phosphor-logging/` on
the BMC. That directory may need to be created.
2. Use busctl to call the Create method to create an event log corresponding
to the message registry entry under test.
-```
-busctl call xyz.openbmc_project.Logging /xyz/openbmc_project/logging \
-xyz.openbmc_project.Logging.Create Create ssa{ss} \
-xyz.openbmc_project.Common.Error.Timeout \
-xyz.openbmc_project.Logging.Entry.Level.Error 1 "TIMEOUT_IN_MSEC" "5"
-```
+ ```sh
+ busctl call xyz.openbmc_project.Logging /xyz/openbmc_project/logging \
+ xyz.openbmc_project.Logging.Create Create ssa{ss} \
+ xyz.openbmc_project.Common.Error.Timeout \
+ xyz.openbmc_project.Logging.Entry.Level.Error 1 "TIMEOUT_IN_MSEC" "5"
+ ```
- 3. Check the PEL that was created using peltool.
- 4. When finished, delete the file from `/etc/phosphor-logging/`.
+ 3. Check the PEL that was created using peltool.
+ 4. When finished, delete the file from `/etc/phosphor-logging/`.