forked from Minki/linux
83432ef3b8
This patch fix some spelling typos in Documentation/ABI/stable. Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
61 lines
2.2 KiB
Plaintext
61 lines
2.2 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).
|