All of lore.kernel.org
 help / color / mirror / Atom feed
From: dhruvaraj S <dhruvaraj@gmail.com>
To: Supreeth Venkatesh <supreeth.venkatesh@amd.com>
Cc: Michael Shen <gpgpgp@google.com>,
	openbmc@lists.ozlabs.org, ed@tanous.net,
	bradleyb@fuzziesquirrel.com, Abinaya.Dhandapani@amd.com
Subject: Re: [RFC] BMC RAS Feature
Date: Tue, 21 Mar 2023 21:56:30 +0530	[thread overview]
Message-ID: <CAK7WosjjdVwNqSwkY2mxYhgAeKdwigtyLryTfJ9r6ShjfbRuCA@mail.gmail.com> (raw)
In-Reply-To: <255d7c9a-ce17-bbe1-7312-990d0221cf36@amd.com>

[-- Attachment #1: Type: text/plain, Size: 4526 bytes --]

On Tue, 21 Mar 2023 at 20:38, Supreeth Venkatesh <supreeth.venkatesh@amd.com>
wrote:

>
> On 3/21/23 05:40, Patrick Williams wrote:
> > On Tue, Mar 21, 2023 at 12:14:45AM -0500, Supreeth Venkatesh wrote:
> >
> >> #### Alternatives Considered
> >>
> >> In-band mechanisms using System Management Mode (SMM) exists.
> >>
> >> However, out of band method to gather RAS data is processor specific.
> >>
> > How does this compare with existing implementations in
> > phosphor-debug-collector.
> Thanks for your feedback. See below.
> > I believe there was some attempt to extend
> > P-D-C previously to handle Intel's crashdump behavior.
> Intel's crashdump interface uses com.intel.crashdump.
> We have implemented com.amd.crashdump based on that reference. However,
> can this be made generic?
>
> PoC below:
>
> busctl tree com.amd.crashdump
>
> └─/com
>    └─/com/amd
>      └─/com/amd/crashdump
>        ├─/com/amd/crashdump/0
>        ├─/com/amd/crashdump/1
>        ├─/com/amd/crashdump/2
>        ├─/com/amd/crashdump/3
>        ├─/com/amd/crashdump/4
>        ├─/com/amd/crashdump/5
>        ├─/com/amd/crashdump/6
>        ├─/com/amd/crashdump/7
>        ├─/com/amd/crashdump/8
>        └─/com/amd/crashdump/9
>
> > The repository
> > currently handles IBM's processors, I think, or maybe that is covered by
> > openpower-debug-collector.
> >
> > In any case, I think you should look at the existing D-Bus interfaces
> > (and associated Redfish implementation) of these repositories and
> > determine if you can use those approaches (or document why now).
> I could not find an existing D-Bus interface for RAS in
> xyz/openbmc_project/.
> It would be helpful if you could point me to it.
>

There is an interface for the dumps generated from the host, which can be
used for these kinds of dumps
https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Dump/Entry/System.interface.yaml

The fault log also provides similar dumps
https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Dump/Entry/FaultLog.interface.yaml


The tree for the dump manager looks like this
`-/xyz
  `-/xyz/openbmc_project
    `-/xyz/openbmc_project/dump
      |-/xyz/openbmc_project/dump/bmc
      | `-/xyz/openbmc_project/dump/bmc/entry
      |   |-/xyz/openbmc_project/dump/bmc/entry/1
      |   |-/xyz/openbmc_project/dump/bmc/entry/2
      |   |-/xyz/openbmc_project/dump/bmc/entry/3
      |   `-/xyz/openbmc_project/dump/bmc/entry/4
      |-/xyz/openbmc_project/dump/faultlog
      |-/xyz/openbmc_project/dump/hardware
      |-/xyz/openbmc_project/dump/hostboot
      |-/xyz/openbmc_project/dump/internal
      | `-/xyz/openbmc_project/dump/internal/manager
      |-/xyz/openbmc_project/dump/resource
      |-/xyz/openbmc_project/dump/sbe
      `-/xyz/openbmc_project/dump/system

There are references to com.intel.crashdump in bmcweb code, but the
> interface itself does not exist in yaml/com/intel/
> we can add com.amd.crashdump as a start or even come up with a new
> generic Dbus interface.
> As far as Redfish implementation is concerned, we are following the
> specification.
> redfish/v1/Systems/system/LogServices/Crashdump schema is being used.
>
> {
>
> "@odata.id": "/redfish/v1/Systems/system/LogServices/Crashdump/Entries",
> "@odata.type": "#LogEntryCollection.LogEntryCollection",
> "Description": "Collection of Crashdump Entries",
> "Members":
>   [
> {"@odata.id":
> "/redfish/v1/Systems/system/LogServices/Crashdump/Entries/0",
> "@odata.type": "#LogEntry.v1_7_0.LogEntry",
> "AdditionalDataURI":
>
> "/redfish/v1/Systems/system/LogServices/Crashdump/Entries/0/ras-error0.cper",
> "Created": "1970-1-1T0:4:12Z",
> "DiagnosticDataType": "OEM",
> "EntryType": "Oem",
> "Id": "0",
> "Name": "CPU Crashdump",
> "OEMDiagnosticDataType": "APMLCrashdump"
> },
> {"@odata.id":
> "/redfish/v1/Systems/system/LogServices/Crashdump/Entries/1",
> "@odata.type": "#LogEntry.v1_7_0.LogEntry",
> "AdditionalDataURI":
>
> "/redfish/v1/Systems/system/LogServices/Crashdump/Entries/1/ras-error1.cper",
> "Created": "1970-1-1T0:4:12Z",
> "DiagnosticDataType": "OEM",
> "EntryType": "Oem",
> "Id": "1",
> "Name": "CPU Crashdump",
> "OEMDiagnosticDataType": "APMLCrashdump"
> },
> ],
> "Members@odata.count": 2,
> "Name": "Open BMC Crashdump Entries"}
> >
>


-- 
--------------
Dhruvaraj S

[-- Attachment #2: Type: text/html, Size: 6552 bytes --]

  reply	other threads:[~2023-03-21 16:27 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-21  5:14 [RFC] BMC RAS Feature Supreeth Venkatesh
2023-03-21 10:40 ` Patrick Williams
2023-03-21 15:07   ` Supreeth Venkatesh
2023-03-21 16:26     ` dhruvaraj S [this message]
2023-03-21 17:25       ` Supreeth Venkatesh
2023-03-22  7:10         ` Lei Yu
2023-03-23  0:07           ` Supreeth Venkatesh
2023-04-03 11:44             ` Patrick Williams
2023-04-03 16:32               ` Supreeth Venkatesh
     [not found]             ` <d65937a46b6fb4f9f94edbdef44af58e@imap.linux.ibm.com>
2023-04-03 16:36               ` Supreeth Venkatesh
2023-07-21 10:29                 ` J Dhanasekar
2023-07-21 14:03                   ` Venkatesh, Supreeth
2023-07-24 13:04                     ` J Dhanasekar
2023-07-24 14:14                       ` Venkatesh, Supreeth
2023-07-25 13:09                         ` J Dhanasekar
2023-07-25 14:02                           ` Venkatesh, Supreeth
2023-07-27 10:20                             ` J Dhanasekar
2023-07-14 22:05 ` Bills, Jason M
2023-07-15  9:01   ` dhruvaraj S
2023-07-24 14:29   ` Venkatesh, Supreeth

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=CAK7WosjjdVwNqSwkY2mxYhgAeKdwigtyLryTfJ9r6ShjfbRuCA@mail.gmail.com \
    --to=dhruvaraj@gmail.com \
    --cc=Abinaya.Dhandapani@amd.com \
    --cc=bradleyb@fuzziesquirrel.com \
    --cc=ed@tanous.net \
    --cc=gpgpgp@google.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=supreeth.venkatesh@amd.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.