openbmc Digest, Vol 41, Issue 94

[George Liu]

Hi:
1. How to read it out after using phosphor:: logging:: log < level >() to write to the log? Is it using ipmitool, journalctl or DBUS? What is the interface? Could anyone elaborate on it?
Thanks








At 2019-01-23 04:02:54, openbmc-request at lists.ozlabs.org wrote:
>Send openbmc mailing list submissions to
>	openbmc at lists.ozlabs.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	https://lists.ozlabs.org/listinfo/openbmc
>or, via email, send a message with subject or body 'help' to
>	openbmc-request at lists.ozlabs.org
>
>You can reach the person managing the list at
>	openbmc-owner at lists.ozlabs.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of openbmc digest..."
>
>
>Today's Topics:
>
>   1. Intel-ipmi-oem repo (Vijay Khemka)
>   2. Re: openbmc Digest, Vol 41, Issue 79 (Bills, Jason M)
>   3. Security Working group meeting - Wednesday Jan 23
>      (Joseph Reynolds)
>   4. Re: couple questions for Event Log (Bills, Jason M)
>   5. Re: Intel-ipmi-oem repo (Brad Bishop)
>   6. Re: Intel-ipmi-oem repo (Patrick Venture)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Tue, 22 Jan 2019 18:16:20 +0000
>From: Vijay Khemka <vijaykhemka at fb.com>
>To: openbmc <openbmc at lists.ozlabs.org>
>Subject: Intel-ipmi-oem repo
>Message-ID: <B67393AC-1915-4999-93D9-944EA6D61D2A at fb.com>
>Content-Type: text/plain; charset="utf-8"
>
>Team,
>Intel-ipmi-oem should be broken and 2 parts, genric and oem specific. I see several functionality in this repo like sensors and storage commands are generic enough to be used by other platform who is using entity manager. So I feel that we should have these functionalities to be moved to a separate common repo which can be used by everyone and this repo can only contain Intel OEM specific IPMI command support.
>
>My 2 cents ?
>
>Regards
>-Vijay
>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20190122/fc526666/attachment-0001.html>
>
>------------------------------
>
>Message: 2
>Date: Tue, 22 Jan 2019 12:10:05 -0800
>From: "Bills, Jason M" <jason.m.bills at linux.intel.com>
>To: openbmc at lists.ozlabs.org
>Subject: Re: openbmc Digest, Vol 41, Issue 79
>Message-ID: <eb00abc8-dc6a-5b5b-2e6e-2c7f0edae9c0 at linux.intel.com>
>Content-Type: text/plain; charset=UTF-8; format=flowed
>
>
>
>On 1/20/2019 7:28 PM, ??? wrote:
>> Hi
>> 1.?I would like to ask any one how to generate BMC logging through 
>> phosphor-logging?
>
>Are you looking at internal BMC logging or system event logging to view 
>through something like 'ipmitool sel'?
>
>For internal BMC logging, you can simply call the 
>phosphor::logging::log<level>() function to add the message to the journal.
>
>I'm not as familiar with it, but phosphor-logging also has report() and 
>commit() capabilities to add error objects to D-Bus.  I believe these 
>objects can be viewed using 'ipmitool sel' commands.
>
>> 2.?When to call the IpmiSelAdd and IpmiSelAddOem methods?
>
>phosphor-sel-logger uses a new approach to log IPMI SEL events to the 
>journal instead of as D-Bus objects.  Whenever an IPMI sensor has an 
>event, it would call IpmiSelAdd or IpmiSelAddOem to log that entry to 
>the journal as a SEL event.
>
>For example, if you have a threshold sensor that crosses a critical 
>threshold, that event can be logged to the SEL by calling IpmiSelAdd.
>
>Alternatively, phosphor-sel-logger can be extended to watch for events 
>from that threshold sensor and log without calling IpmiSelAdd.
>
>> 3. Write the log to journalctl through phosphor-sel-logger. Could you 
>> read it through the ipmiStorageGetSELInfo method of intel-ipmi-oem?
>
>Yes.  Today, however, it is tied to the sensor path on D-Bus to get some 
>of the information for the SEL record.  Without that mapping, some of 
>the data returned by ipmiStorageGetSELInfo may not be accurate.
>
>> Thanks
>> 
>
>
>------------------------------
>
>Message: 3
>Date: Tue, 22 Jan 2019 14:19:43 -0600
>From: Joseph Reynolds <jrey at linux.vnet.ibm.com>
>To: openbmc at lists.ozlabs.org
>Subject: Security Working group meeting - Wednesday Jan 23
>Message-ID: <fd3a4b5517ace5934b5821d6648cbb25 at linux.vnet.ibm.com>
>Content-Type: text/plain; charset=US-ASCII; format=flowed
>
>This is a reminder of the OpenBMC Security Working Group meeting 
>scheduled for this Wednesday January 23 at 10:00am PDT.
>
>Topics may include:
>- Followup questions from the ARMv8 TrustZone presentation
>- Questions about recent security vulnerabilities
>- BMC asset and threat models
>
>Access, agenda, and notes are in the wiki:
>https://github.com/openbmc/openbmc/wiki/Security-working-group
>
>- Joseph
>
>
>
>------------------------------
>
>Message: 4
>Date: Tue, 22 Jan 2019 12:26:55 -0800
>From: "Bills, Jason M" <jason.m.bills at linux.intel.com>
>To: openbmc at lists.ozlabs.org
>Subject: Re: couple questions for Event Log
>Message-ID: <01fb8bcf-87a7-2f12-b9b1-fe3be9896ea6 at linux.intel.com>
>Content-Type: text/plain; charset=UTF-8; format=flowed
>
>
>
>On 1/21/2019 1:43 AM, George Liu wrote:
>> Hi:
>> 1.?Could anyone use impitool sel list to read values after calling the 
>> sd_journal_send method?
>
>No, not really.  sd_journal_send only adds a log entry with metadata to 
>the journal.
>
>phosphor-sel-logger adds special metadata to identify the entry as an 
>IPMI sel record.  A special implementation of the 'Get SEL Entry' IPMI 
>command is needed to find the journal entries with SEL metadata and 
>construct the IPMI SEL records.  An example implementation is here: 
>https://gerrit.openbmc-project.xyz/c/openbmc/intel-ipmi-oem/+/16280.
>
>> 2.?Calling the startThresholdEventMonitor method of the 
>> phosphor-sel-logger module, why get the values of max, min, sensorVal 
>> are all 0? But I can get the correct values through dbus.
>
>Calling startThresholdEventMonitor() should start a D-Bus match to watch 
>for any changes to 'xyz.openbmc_project.Sensor.Threshold' properties. 
>The 'Alarm' properties are used to know when a sensor threshold is 
>crossed and log that event automatically.
>
>When the match is triggered, the callback uses the same bus and path to 
>get the properties from the 'xyz.openbmc_project.Sensor.Value' interface 
>which has the MaxValue, MinValue, and Value properties for the sensor.
>
>So, is the issue you see that after the match is triggered and the 
>'xyz.openbmc_project.Sensor.Value' properties are read from that path, 
>they are all 0, but if you manually read the properties from the same 
>path, they are correct?
>
>> Thanks
>> 
>> 
>
>
>------------------------------
>
>Message: 5
>Date: Tue, 22 Jan 2019 15:53:38 -0500
>From: Brad Bishop <bradleyb at fuzziesquirrel.com>
>To: Vijay Khemka <vijaykhemka at fb.com>
>Cc: openbmc <openbmc at lists.ozlabs.org>
>Subject: Re: Intel-ipmi-oem repo
>Message-ID: <20190122205338.m2giw4ghhievyssc at thinkpad>
>Content-Type: text/plain; charset=utf-8
>
>On Tue, Jan 22, 2019 at 06:16:20PM +0000, Vijay Khemka wrote:
>> Team,
>> Intel-ipmi-oem should be broken and 2 parts, genric and oem specific. I see several functionality in this repo like sensors and storage commands are generic enough to be used by other platform who is using entity manager. So I feel that we should have these functionalities to be moved to a separate common repo which can be used by everyone and this repo can only contain Intel OEM specific IPMI command support.
>> 
>> My 2 cents ?
>
>In general I support the goal here.
>
>More repos, sure.  Let me know what you want them called, who the
>maintainers of each should be, and confirm that they can be licensed
>as Apache-2.0.
>
>Sorry Vijay - I'm going to hijack your thread.  This is something
>I've been thinking about lately and your note put it at a tipping
>point for me.
>
>We have evolved into a bit of a wild-west culture as far as putting code
>(repos) up in the openbmc namespace.  There are simply no rules at all.
>Anyone can simply ask Brad for a repo and it gets created, no questions
>asked, no accountability.
>
>So I guess a quick poll - does anyone find this concerning (or not)?
>
>fwiw, I think I'm ok with this model at this point in the project,
>assuming that the rules (or lack thereof) apply to everyone equally.
>
>thx - brad
>
>
>------------------------------
>
>Message: 6
>Date: Tue, 22 Jan 2019 13:02:37 -0800
>From: Patrick Venture <venture at google.com>
>To: Brad Bishop <bradleyb at fuzziesquirrel.com>
>Cc: Vijay Khemka <vijaykhemka at fb.com>, openbmc
>	<openbmc at lists.ozlabs.org>
>Subject: Re: Intel-ipmi-oem repo
>Message-ID:
>	<CAO=notxTxQgmvjofWZqozZGLYwDbQwNRnneGvU4qV2L-_yCF7g at mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>On Tue, Jan 22, 2019 at 12:53 PM Brad Bishop <bradleyb at fuzziesquirrel.com>
>wrote:
>
>> On Tue, Jan 22, 2019 at 06:16:20PM +0000, Vijay Khemka wrote:
>> > Team,
>> > Intel-ipmi-oem should be broken and 2 parts, genric and oem specific. I
>> see several functionality in this repo like sensors and storage commands
>> are generic enough to be used by other platform who is using entity
>> manager. So I feel that we should have these functionalities to be moved to
>> a separate common repo which can be used by everyone and this repo can only
>> contain Intel OEM specific IPMI command support.
>> >
>> > My 2 cents ?
>>
>> In general I support the goal here.
>>
>> More repos, sure.  Let me know what you want them called, who the
>> maintainers of each should be, and confirm that they can be licensed
>> as Apache-2.0.
>>
>> Sorry Vijay - I'm going to hijack your thread.  This is something
>> I've been thinking about lately and your note put it at a tipping
>> point for me.
>>
>> We have evolved into a bit of a wild-west culture as far as putting code
>> (repos) up in the openbmc namespace.  There are simply no rules at all.
>> Anyone can simply ask Brad for a repo and it gets created, no questions
>> asked, no accountability.
>>
>> So I guess a quick poll - does anyone find this concerning (or not)?
>>
>
>I'm holding the hypothesis that things expand for a bit, and then fall back
>onto themselves. -- which maybe isn't the best approach.  I could be wrong,
>it could be the universe expanding and accelerating, which has the
>unfortunate consequence of moving galaxies further apart -- code less
>compatible or allowing more duplication.
>
>
>>
>> fwiw, I think I'm ok with this model at this point in the project,
>> assuming that the rules (or lack thereof) apply to everyone equally.
>>
>> thx - brad
>>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20190122/06d6a000/attachment.html>
>
>End of openbmc Digest, Vol 41, Issue 94
>***************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20190123/43bdc100/attachment-0001.html>