<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style="font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 10pt;"><div>Hi Supreeth Venkatesh,<br></div><div><br></div><div style="color: rgb(34, 34, 34); font-family: Arial, Helvetica, sans-serif; font-size: small; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">Does this RAS feature work for the Daytona Platform.  i have been working in openBMC development for the Daytonax platform. <br></div><div style="color: rgb(34, 34, 34); font-family: Arial, Helvetica, sans-serif; font-size: small; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">If this RAS works for Daytona Platform. I will include it in my project. <br></div><div style="color: rgb(34, 34, 34); font-family: Arial, Helvetica, sans-serif; font-size: small; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><br></div><div style="color: rgb(34, 34, 34); font-family: Arial, Helvetica, sans-serif; font-size: small; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">Please provide your suggestions. <br></div><div><br></div><div>Thanks,<br></div><div>Dhanasekar</div><div><br></div><div id="Zm-_Id_-Sgn" data-zbluepencil-ignore="true" data-sigid="818525000000014003"><div><br></div></div><div><br></div><div class="zmail_extra_hr" style="border-top: 1px solid rgb(204, 204, 204); height: 0px; margin-top: 10px; margin-bottom: 10px; line-height: 0px;"><br></div><div class="zmail_extra" data-zbluepencil-ignore="true"><div><br></div><div id="Zm-_Id_-Sgn1">---- On Mon, 03 Apr 2023 22:06:24 +0530 <b>Supreeth Venkatesh <supreeth.venkatesh@amd.com></b> wrote ---<br></div><div><br></div><blockquote id="blockquote_zmail" style="margin: 0px;"><div><br>On 3/23/23 13:57, Zane Shelley wrote: <br>> Caution: This message originated from an External Source. Use proper <br>> caution when opening attachments, clicking links, or responding. <br>> <br>> <br>> On 2023-03-22 19:07, Supreeth Venkatesh wrote: <br>>> On 3/22/23 02:10, Lei Yu wrote: <br>>>> Caution: This message originated from an External Source. Use proper <br>>>> caution when opening attachments, clicking links, or responding. <br>>>> <br>>>> <br>>>>>> On Tue, 21 Mar 2023 at 20:38, Supreeth Venkatesh <br>>>>>> <<a href="mailto:supreeth.venkatesh@amd.com" target="_blank">supreeth.venkatesh@amd.com</a>> wrote: <br>>>>>> <br>>>>>> <br>>>>>>      On 3/21/23 05:40, Patrick Williams wrote: <br>>>>>>      > On Tue, Mar 21, 2023 at 12:14:45AM -0500, Supreeth Venkatesh <br>>>>>> wrote: <br>>>>>>      > <br>>>>>>      >> #### Alternatives Considered <br>>>>>>      >> <br>>>>>>      >> In-band mechanisms using System Management Mode (SMM) <br>>>>>> exists. <br>>>>>>      >> <br>>>>>>      >> However, out of band method to gather RAS data is processor <br>>>>>>      specific. <br>>>>>>      >> <br>>>>>>      > How does this compare with existing implementations in <br>>>>>>      > phosphor-debug-collector. <br>>>>>>      Thanks for your feedback. See below. <br>>>>>>      > I believe there was some attempt to extend <br>>>>>>      > P-D-C previously to handle Intel's crashdump behavior. <br>>>>>>      Intel's crashdump interface uses com.intel.crashdump. <br>>>>>>      We have implemented com.amd.crashdump based on that reference. <br>>>>>>      However, <br>>>>>>      can this be made generic? <br>>>>>> <br>>>>>>      PoC below: <br>>>>>> <br>>>>>>      busctl tree com.amd.crashdump <br>>>>>> <br>>>>>>      └─/com <br>>>>>>         └─/com/amd <br>>>>>>           └─/com/amd/crashdump <br>>>>>>             ├─/com/amd/crashdump/0 <br>>>>>>             ├─/com/amd/crashdump/1 <br>>>>>>             ├─/com/amd/crashdump/2 <br>>>>>>             ├─/com/amd/crashdump/3 <br>>>>>>             ├─/com/amd/crashdump/4 <br>>>>>>             ├─/com/amd/crashdump/5 <br>>>>>>             ├─/com/amd/crashdump/6 <br>>>>>>             ├─/com/amd/crashdump/7 <br>>>>>>             ├─/com/amd/crashdump/8 <br>>>>>>             └─/com/amd/crashdump/9 <br>>>>>> <br>>>>>>      > The repository <br>>>>>>      > currently handles IBM's processors, I think, or maybe that is <br>>>>>>      covered by <br>>>>>>      > openpower-debug-collector. <br>>>>>>      > <br>>>>>>      > In any case, I think you should look at the existing D-Bus <br>>>>>>      interfaces <br>>>>>>      > (and associated Redfish implementation) of these repositories <br>>>>>> and <br>>>>>>      > determine if you can use those approaches (or document why <br>>>>>> now). <br>>>>>>      I could not find an existing D-Bus interface for RAS in <br>>>>>>      xyz/openbmc_project/. <br>>>>>>      It would be helpful if you could point me to it. <br>>>>>> <br>>>>>> <br>>>>>> There is an interface for the dumps generated from the host, which <br>>>>>> can <br>>>>>> be used for these kinds of dumps <br>>>>>> <a href="https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Dump/Entry/System.interface.yaml" target="_blank">https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Dump/Entry/System.interface.yaml</a> <br>>>>>> <br>>>>>> <br>>>>>> The fault log also provides similar dumps <br>>>>>> <a href="https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Dump/Entry/FaultLog.interface.yaml" target="_blank">https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Dump/Entry/FaultLog.interface.yaml</a> <br>>>>>> <br>>>>>> <br>>>>> ThanksDdhruvraj. The interface looks useful for the purpose. However, <br>>>>> the current BMCWEB implementation references <br>>>>> <a href="https://github.com/openbmc/bmcweb/blob/master/redfish-core/lib/log_services.hpp" target="_blank">https://github.com/openbmc/bmcweb/blob/master/redfish-core/lib/log_services.hpp</a> <br>>>>> <br>>>>> [com.intel.crashdump] <br>>>>> constexpr char const* crashdumpPath = "/com/intel/crashdump"; <br>>>>> <br>>>>> constexpr char const* crashdumpInterface = "com.intel.crashdump"; <br>>>>> constexpr char const* crashdumpObject = "com.intel.crashdump"; <br>>>>> <br>>>>> <a href="https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Dump/Entry/System.interface.yaml" target="_blank">https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Dump/Entry/System.interface.yaml</a> <br>>>>> <br>>>>> or <br>>>>> <a href="https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Dump/Entry/FaultLog.interface.yaml" target="_blank">https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Dump/Entry/FaultLog.interface.yaml</a> <br>>>>> <br>>>>> is it exercised in Redfish logservices? <br>>>> In our practice, a plugin `tools/dreport.d/plugins.d/acddump` is added <br>>>> to copy the crashdump json file to the dump tarball. <br>>>> The crashdump tool (Intel or AMD) could trigger a dump after the <br>>>> crashdump is completed, and then we could get a dump entry containing <br>>>> the crashdump. <br>>> Thanks Lei Yu for your input. We are using Redfish to retrieve the <br>>> CPER binary file which can then be passed through a plugin/script for <br>>> detailed analysis. <br>>> In any case irrespective of whichever Dbus interface we use, we need a <br>>> repository which will gather data from AMD processor via APML as per <br>>> AMD design. <br>>> APML <br>>> Spec: <a href="https://www.amd.com/system/files/TechDocs/57019-A0-PUB_3.00.zip" target="_blank">https://www.amd.com/system/files/TechDocs/57019-A0-PUB_3.00.zip</a> <br>>> Can someone please help create bmc-ras or amd-debug-collector <br>>> repository as there are instances of openpower-debug-collector <br>>> repository used for Open Power systems? <br>>>> <br>>>> <br>>>> -- <br>>>> BRs, <br>>>> Lei YU <br>> I am interested in possibly standardizing some of this. IBM POWER has <br>> several related components. openpower-hw-diags is a service that will <br>> listen for the hardware interrupts via a GPIO pin. When an error is <br>> detected, it will use openpower-libhei to query hardware registers to <br>> determine what happened. Based on that information openpower-hw-diags <br>> will generate a PEL, which is an extended log in phosphor-logging, that <br>> is used to tell service what to replace if necessary. Afterward, <br>> openpower-hw-diags will initiate openpower-debug-collector, which <br>> gathers a significant amount of data from the hardware for additional <br>> debug when necessary. I wrote openpower-libhei to be fairly agnostic. It <br>> uses data files (currently XML, but moving to JSON) to define register <br>> addresses and rules for isolation. openpower-hw-diags is fairly POWER <br>> specific, but I can see some parts can be made generic. Dhruv would have <br>> to help with openpower-debug-collector. <br>Thank you. Lets collaborate in standardizing some aspects of it. <br>> <br>> Regarding creation of a new repository, I think we'll need to have some <br>> more collaboration to determine the scope before creating it. It <br>> certainly sounds like we are doing similar things, but we need to <br>> determine if enough can be abstracted to make it worth our time. <br>I have put in a request here: <br><a href="https://github.com/openbmc/technical-oversight-forum/issues/24" target="_blank">https://github.com/openbmc/technical-oversight-forum/issues/24</a> <br>Please chime in. <br></div></blockquote></div><div><br></div></div><br></body></html>