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