From 9ca8dbcc65cfc63d6f5ef3312a33184e1d726e00 Mon Sep 17 00:00:00 2001 From: Yunhong Jiang Date: Tue, 4 Aug 2015 12:17:53 -0700 Subject: Add the rt linux 4.1.3-rt3 as base Import the rt linux 4.1.3-rt3 as OPNFV kvm base. It's from git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git linux-4.1.y-rt and the base is: commit 0917f823c59692d751951bf5ea699a2d1e2f26a2 Author: Sebastian Andrzej Siewior Date: Sat Jul 25 12:13:34 2015 +0200 Prepare v4.1.3-rt3 Signed-off-by: Sebastian Andrzej Siewior We lose all the git history this way and it's not good. We should apply another opnfv project repo in future. Change-Id: I87543d81c9df70d99c5001fbdf646b202c19f423 Signed-off-by: Yunhong Jiang --- .../ABI/stable/sysfs-firmware-opal-elog | 60 ++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 kernel/Documentation/ABI/stable/sysfs-firmware-opal-elog (limited to 'kernel/Documentation/ABI/stable/sysfs-firmware-opal-elog') diff --git a/kernel/Documentation/ABI/stable/sysfs-firmware-opal-elog b/kernel/Documentation/ABI/stable/sysfs-firmware-opal-elog new file mode 100644 index 000000000..e1f3058f5 --- /dev/null +++ b/kernel/Documentation/ABI/stable/sysfs-firmware-opal-elog @@ -0,0 +1,60 @@ +What: /sys/firmware/opal/elog +Date: Feb 2014 +Contact: Stewart Smith +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 (curently just acknowledge). \ No newline at end of file -- cgit 1.2.3-korg