All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stewart Smith <stewart@linux.ibm.com>
To: Alexander Amelkin <a.amelkin@yadro.com>,
	openbmc@lists.ozlabs.org,
	Timothy Pearson <tpearson@raptorengineering.com>
Subject: Re: Parse PELs sent by OpenPOWER host firmware
Date: Thu, 12 Apr 2018 15:32:17 +1000	[thread overview]
Message-ID: <877epdj8gu.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <4467ab37-c09e-c09c-306c-3447c651bf7f@yadro.com>

Alexander Amelkin <a.amelkin@yadro.com> writes:
> 14.03.2018 03:36, Stewart Smith wrote:
>> Deepak Kodihalli <dkodihal@linux.vnet.ibm.com> writes:
>>> The SELs/eSELs (System Event Log) that OpenBMC receives from 
>>> hostboot/skiboot today are not interpreted, and are dumped as-is in a 
>>> property of the error log D-Bus object. This means that if there's a PEL 
>>> (Platform Event Log) hidden in the eSEL, admins/users of the error log 
>>> need to depend on external tools to parse the PEL to human readable
>>> text.
>> My lack of love for PELs is probably fairly well known, but even if we
>> replace them down the line, I think there's opportunity here for making
>> things better for users (including myself).
>
> Just my 2 cents. The IPMI-standardized SELs are good first of all
> because of IPMI-standardized PEFs and PETs.
>
> Being able to decode the OEM SEL records is not just convenient for the
> users, but will also let them easily attach PEFs to such events if they
> want to. That's of course when PEFs are supported in OpenBMC which is
> currently not true, AFAIK.
>
> As a maintainer of ipmitool I can promise to promptly include the
> OpenPOWER event record decoder into ipmitool upstream code. All I need
> is the information on how to decode those events. So far I'm planning to
> try and deduce this information from hostboot and opal sources.

(Adding in Tim from Raptor as we were talking about this yesterday)

There's opal-elog-parse, which is part of ppc64-diag, and there's
https://github.com/open-power/libopalevents which is a quite
bitrotted attempt to turn parsing it into a shared library rather than
just a binary.

there's also a (internal but in the process of being open sourced)
implementation called 'errl' which is what has shipped on IBM FSP
systems forever (but that for whatever reason we ended up doing
opal-elog-parse rather than open sourcing it back in 2014).

From hostboot, ./src/build/debug/eSEL.pl is the script that extracts
things from the BMC IIRC.

Now, there *is* a spec for the Platfrom Error Log format, which I have
previously tried to get out into the open... so I encourage you to find
all your IBM contacts and bug them about it.

That being said, I'm not convinced PEL is the right thing to continue to
exist. It's Yet Another Custom Binary Format, and there's probably
enough of those in the world as it is.

-- 
Stewart Smith
OPAL Architect, IBM.

  reply	other threads:[~2018-04-12  5:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-13 13:39 Parse PELs sent by OpenPOWER host firmware Deepak Kodihalli
2018-03-14  0:36 ` Stewart Smith
2018-04-09 10:47   ` Alexander Amelkin
2018-04-12  5:32     ` Stewart Smith [this message]
2018-03-19  6:13 ` Vasant Hegde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877epdj8gu.fsf@linux.vnet.ibm.com \
    --to=stewart@linux.ibm.com \
    --cc=a.amelkin@yadro.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=tpearson@raptorengineering.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.