1774fea1aSStewart SmithWhat: /sys/firmware/opal/elog 2774fea1aSStewart SmithDate: Feb 2014 3774fea1aSStewart SmithContact: Stewart Smith <stewart@linux.vnet.ibm.com> 4774fea1aSStewart SmithDescription: 5774fea1aSStewart Smith This directory exposes error log entries retrieved 6774fea1aSStewart Smith through the OPAL firmware interface. 7774fea1aSStewart Smith 8774fea1aSStewart Smith Each error log is identified by a unique ID and will 9774fea1aSStewart Smith exist until explicitly acknowledged to firmware. 10774fea1aSStewart Smith 11774fea1aSStewart Smith Each log entry has a directory in /sys/firmware/opal/elog. 12774fea1aSStewart Smith 13774fea1aSStewart Smith Log entries may be purged by the service processor 14774fea1aSStewart Smith before retrieved by firmware or retrieved/acknowledged by 15774fea1aSStewart Smith Linux if there is no room for more log entries. 16774fea1aSStewart Smith 17774fea1aSStewart Smith In the event that Linux has retrieved the log entries 18774fea1aSStewart Smith but not explicitly acknowledged them to firmware and 19774fea1aSStewart Smith the service processor needs more room for log entries, 20774fea1aSStewart Smith the only remaining copy of a log message may be in 21774fea1aSStewart Smith Linux. 22774fea1aSStewart Smith 23774fea1aSStewart Smith Typically, a user space daemon will monitor for new 24774fea1aSStewart Smith entries, read them out and acknowledge them. 25774fea1aSStewart Smith 26774fea1aSStewart Smith The service processor may be able to store more log 27774fea1aSStewart Smith entries than firmware can, so after you acknowledge 28774fea1aSStewart Smith an event from Linux you may instantly get another one 29774fea1aSStewart Smith from the queue that was generated some time in the past. 30774fea1aSStewart Smith 31774fea1aSStewart Smith The raw log format is a binary format. We currently 32774fea1aSStewart Smith do not parse this at all in kernel, leaving it up to 33774fea1aSStewart Smith user space to solve the problem. In future, we may 34774fea1aSStewart Smith do more parsing in kernel and add more files to make 35774fea1aSStewart Smith it easier for simple user space processes to extract 36774fea1aSStewart Smith more information. 37774fea1aSStewart Smith 38774fea1aSStewart Smith For each log entry (directory), there are the following 39774fea1aSStewart Smith files: 40774fea1aSStewart Smith 41774fea1aSStewart Smith id: An ASCII representation of the ID of the 42774fea1aSStewart Smith error log, in hex - e.g. "0x01". 43774fea1aSStewart Smith 44774fea1aSStewart Smith type: An ASCII representation of the type id and 45774fea1aSStewart Smith description of the type of error log. 46774fea1aSStewart Smith Currently just "0x00 PEL" - platform error log. 47774fea1aSStewart Smith In the future there may be additional types. 48774fea1aSStewart Smith 49774fea1aSStewart Smith raw: A read-only binary file that can be read 50774fea1aSStewart Smith to get the raw log entry. These are 51774fea1aSStewart Smith <16kb, often just hundreds of bytes and 52774fea1aSStewart Smith "average" 2kb. 53774fea1aSStewart Smith 54774fea1aSStewart Smith acknowledge: Writing 'ack' to this file will acknowledge 55774fea1aSStewart Smith the error log to firmware (and in turn 56774fea1aSStewart Smith the service processor, if applicable). 57774fea1aSStewart Smith Shortly after acknowledging it, the log 58774fea1aSStewart Smith entry will be removed from sysfs. 59774fea1aSStewart Smith Reading this file will list the supported 60774fea1aSStewart Smith operations (curently just acknowledge).