98913408c5
Several entries at the stable ABI files won't parse if we pass them directly to the ReST output. Adjust them, in order to allow adding their contents as-is at the stable ABI book. Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/467a0dfbcdf00db710a629d3fe4a2563750339d8.1604042072.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
63 lines
2.3 KiB
Plaintext
63 lines
2.3 KiB
Plaintext
What: /sys/firmware/opal/elog
|
|
Date: Feb 2014
|
|
Contact: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Description:
|
|
This directory exposes error log entries retrieved
|
|
through the OPAL firmware interface.
|
|
|
|
Each error log is identified by a unique ID and will
|
|
exist until explicitly acknowledged to firmware.
|
|
|
|
Each log entry has a directory in /sys/firmware/opal/elog.
|
|
|
|
Log entries may be purged by the service processor
|
|
before retrieved by firmware or retrieved/acknowledged by
|
|
Linux if there is no room for more log entries.
|
|
|
|
In the event that Linux has retrieved the log entries
|
|
but not explicitly acknowledged them to firmware and
|
|
the service processor needs more room for log entries,
|
|
the only remaining copy of a log message may be in
|
|
Linux.
|
|
|
|
Typically, a user space daemon will monitor for new
|
|
entries, read them out and acknowledge them.
|
|
|
|
The service processor may be able to store more log
|
|
entries than firmware can, so after you acknowledge
|
|
an event from Linux you may instantly get another one
|
|
from the queue that was generated some time in the past.
|
|
|
|
The raw log format is a binary format. We currently
|
|
do not parse this at all in kernel, leaving it up to
|
|
user space to solve the problem. In future, we may
|
|
do more parsing in kernel and add more files to make
|
|
it easier for simple user space processes to extract
|
|
more information.
|
|
|
|
For each log entry (directory), there are the following
|
|
files:
|
|
|
|
============== ================================================
|
|
id: An ASCII representation of the ID of the
|
|
error log, in hex - e.g. "0x01".
|
|
|
|
type: An ASCII representation of the type id and
|
|
description of the type of error log.
|
|
Currently just "0x00 PEL" - platform error log.
|
|
In the future there may be additional types.
|
|
|
|
raw: A read-only binary file that can be read
|
|
to get the raw log entry. These are
|
|
<16kb, often just hundreds of bytes and
|
|
"average" 2kb.
|
|
|
|
acknowledge: Writing 'ack' to this file will acknowledge
|
|
the error log to firmware (and in turn
|
|
the service processor, if applicable).
|
|
Shortly after acknowledging it, the log
|
|
entry will be removed from sysfs.
|
|
Reading this file will list the supported
|
|
operations (currently just acknowledge).
|
|
============== ================================================
|