Documentation/ABI/stable/sysfs-firmware-opal-elog

Source file repositories/reference/linux-study-clean/Documentation/ABI/stable/sysfs-firmware-opal-elog

File Facts

System
Linux kernel
Corpus path
Documentation/ABI/stable/sysfs-firmware-opal-elog
Extension
[no extension]
Size
2343 bytes
Lines
63
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: Documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

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).
		==============  ================================================

Annotation

Implementation Notes