1*774fea1aSStewart SmithWhat: /sys/firmware/opal/elog 2*774fea1aSStewart SmithDate: Feb 2014 3*774fea1aSStewart SmithContact: Stewart Smith <stewart@linux.vnet.ibm.com> 4*774fea1aSStewart SmithDescription: 5*774fea1aSStewart Smith This directory exposes error log entries retrieved 6*774fea1aSStewart Smith through the OPAL firmware interface. 7*774fea1aSStewart Smith 8*774fea1aSStewart Smith Each error log is identified by a unique ID and will 9*774fea1aSStewart Smith exist until explicitly acknowledged to firmware. 10*774fea1aSStewart Smith 11*774fea1aSStewart Smith Each log entry has a directory in /sys/firmware/opal/elog. 12*774fea1aSStewart Smith 13*774fea1aSStewart Smith Log entries may be purged by the service processor 14*774fea1aSStewart Smith before retrieved by firmware or retrieved/acknowledged by 15*774fea1aSStewart Smith Linux if there is no room for more log entries. 16*774fea1aSStewart Smith 17*774fea1aSStewart Smith In the event that Linux has retrieved the log entries 18*774fea1aSStewart Smith but not explicitly acknowledged them to firmware and 19*774fea1aSStewart Smith the service processor needs more room for log entries, 20*774fea1aSStewart Smith the only remaining copy of a log message may be in 21*774fea1aSStewart Smith Linux. 22*774fea1aSStewart Smith 23*774fea1aSStewart Smith Typically, a user space daemon will monitor for new 24*774fea1aSStewart Smith entries, read them out and acknowledge them. 25*774fea1aSStewart Smith 26*774fea1aSStewart Smith The service processor may be able to store more log 27*774fea1aSStewart Smith entries than firmware can, so after you acknowledge 28*774fea1aSStewart Smith an event from Linux you may instantly get another one 29*774fea1aSStewart Smith from the queue that was generated some time in the past. 30*774fea1aSStewart Smith 31*774fea1aSStewart Smith The raw log format is a binary format. We currently 32*774fea1aSStewart Smith do not parse this at all in kernel, leaving it up to 33*774fea1aSStewart Smith user space to solve the problem. In future, we may 34*774fea1aSStewart Smith do more parsing in kernel and add more files to make 35*774fea1aSStewart Smith it easier for simple user space processes to extract 36*774fea1aSStewart Smith more information. 37*774fea1aSStewart Smith 38*774fea1aSStewart Smith For each log entry (directory), there are the following 39*774fea1aSStewart Smith files: 40*774fea1aSStewart Smith 41*774fea1aSStewart Smith id: An ASCII representation of the ID of the 42*774fea1aSStewart Smith error log, in hex - e.g. "0x01". 43*774fea1aSStewart Smith 44*774fea1aSStewart Smith type: An ASCII representation of the type id and 45*774fea1aSStewart Smith description of the type of error log. 46*774fea1aSStewart Smith Currently just "0x00 PEL" - platform error log. 47*774fea1aSStewart Smith In the future there may be additional types. 48*774fea1aSStewart Smith 49*774fea1aSStewart Smith raw: A read-only binary file that can be read 50*774fea1aSStewart Smith to get the raw log entry. These are 51*774fea1aSStewart Smith <16kb, often just hundreds of bytes and 52*774fea1aSStewart Smith "average" 2kb. 53*774fea1aSStewart Smith 54*774fea1aSStewart Smith acknowledge: Writing 'ack' to this file will acknowledge 55*774fea1aSStewart Smith the error log to firmware (and in turn 56*774fea1aSStewart Smith the service processor, if applicable). 57*774fea1aSStewart Smith Shortly after acknowledging it, the log 58*774fea1aSStewart Smith entry will be removed from sysfs. 59*774fea1aSStewart Smith Reading this file will list the supported 60*774fea1aSStewart Smith operations (curently just acknowledge).