David,
>
> It won't happen before the 3.0 release, but I'll try to take a look at
> this. By the way, I've also come across a bug in the functions that
> read the SEL, and I have been working on that, as well as some other
> enhancements in that area. I'll enter Tracker reports for those,
> targeted for 3.0.x.
>
OK, let's see what you will find out.
>> All OpenHPI clients do that!
>>
>
> I guess that's how a non-conformant behavior has gone undetected for so
> long. :-)
>
Now we have you on guard! :)
> And, if it worked right, then you wouldn't even be able to open a
> session until that initial discovery is done, which would mean that the
> call to saHpiDiscover() should never be required.
From my point of view the code:
-------------------
saHpiSessionOpen();
saHpiDiscover();
...
-------------------
is better than
-------------------
do {
rv = saHpiSessionOpen();
while ( rv != SA_OK );
...
-------------------
Anton Pak
On Fri, 07 Oct 2011 23:23:02 +0400, David McKinley <[email protected]>
wrote:
> Hi Anton,
>
> Comments inserted below. Thanks for your inputs!
>
> David
>
>> -----Original Message-----
>> From: Anton Pak [mailto:[email protected]]
>> Sent: Friday, October 07, 2011 1:34 PM
>> To: [email protected]; David McKinley
>> Subject: Re: [Openhpi-devel] saHpiDiscover() Required?
>>
>> David,
>>
>> See my comments below.
>>
>> On Fri, 07 Oct 2011 21:02:35 +0400, David McKinley
>> <[email protected]>
>> wrote:
>>
>> > Anton,
>> >
>> > What I saw could be described as the first hot swap event for each
>> > resource not being delivered. This sounds like a pretty serious bug,
>> in
>> > its own right! Is it going to be fixed in 3.0?
>>
>> Well, we don't have any active IPMI Direct maintainer right now.
>> So the chances are not good to get it fixed.
>>
>> PPS offers proprietary plug-in with IPMI Direct origins.
>> So my participation in the plugin work is restricted.
>> However I can discuss IPMI Direct bugs at some extent.
>>
>> First hot swap event in IPMI Direct is always Current State -> Current
>> State.
>> Daemon just ignores such events (they have very long history I'd say).
>>
>
> It won't happen before the 3.0 release, but I'll try to take a look at
> this. By the way, I've also come across a bug in the functions that
> read the SEL, and I have been working on that, as well as some other
> enhancements in that area. I'll enter Tracker reports for those,
> targeted for 3.0.x.
>
>> >
>> > In actuality, though, what seems like is happening in my particular
>> > scenario, is that the daemon is allowing new sessions to be created
>> too
>> > soon, while the initialization is still going on. It seems that it
>> is
>> > still doing an initial discovery operation to populate the RPT and
>> RDR
>> > data, but allows a client session anyway.
>> >
>> > I have not had an opportunity to dig into this further - it is easy
>> to
>> > work around by making sure that the user application calls
>> > saHpiDiscover() immediately after a session is opened.
>>
>> All OpenHPI clients do that!
>>
>
> I guess that's how a non-conformant behavior has gone undetected for so
> long. :-)
>
>
>
>> > That's just distasteful in my opinion, because it imposes some
>> overhead
>> > that should not be required, and because I still have the scars from
>> the
>> > struggle to make sure the specification was unambiguous in saying
>> that
>> > it should not be required. :-)
>>
>> I think overhead is not very significant. The plugin does initial
>> discovery once
>> at startup and then just returns SA_OK to discover call.
>>
>
> And, if it worked right, then you wouldn't even be able to open a
> session until that initial discovery is done, which would mean that the
> call to saHpiDiscover() should never be required.
>
>
>> Anton Pak
>>
>> >
>> > Cheers,
>> >
>> > David
>> >
>> >> -----Original Message-----
>> >> From: Anton Pak [mailto:[email protected]]
>> >> Sent: Friday, October 07, 2011 11:52 AM
>> >> To: [email protected]; David McKinley
>> >> Subject: Re: [Openhpi-devel] saHpiDiscover() Required?
>> >>
>> >> David, Shyamala,
>> >>
>> >> Seems it is an ipmidirect issue.
>> >> I compiled hpi_shell with commented saHpiDiscover() call.
>> >> Then tried connecting it to OpenHPI daemon 2.16 and 2.17 with PPS
>> plug-
>> >> in
>> >> right after daemon startup.
>> >>
>> >> In 2.16 there was about 10 second gap before events began to
>> deliver.
>> >> In 2.17 events began deliver immediately.
>> >> And all events were delivered in both cases.
>> >>
>> >> Another ipmidirect issue: the first hot swap event from any resource
>> is
>> >> not delivered.
>> >>
>> >> Anton Pak
>> >>
>> >> On Wed, 05 Oct 2011 18:26:07 +0400, David McKinley
>> >> <[email protected]>
>> >> wrote:
>> >>
>> >> > Hi Shyamala,
>> >> >
>> >> > That is not the behavior I see. Does this maybe depend on the
>> >> plugin?
>> >> > I am using the ipmidirect plugin, connected via LAN to an IPMI 2.0
>> >> > compliant chassis manager in a non-ATCA platform.
>> >> >
>> >> > First of all, it is impossible to subscribe for events before
>> >> starting
>> >> > the daemon, because an attempt to call saHpiSessionOpen() returns
>> an
>> >> > error, SA_ERR_HPI_NO_RESPONSE.
>> >> >
>> >> > After starting the daemon, it continues to return that error to
>> >> > saHpiSessionOpen() for some time. I keep retrying the call, until
>> >> > eventually it returns SA_OK.
>> >> >
>> >> > At that point, I immediately call saHpiSubscribe(), and then
>> >> alternately
>> >> > call saHpiEventGet() and saHpiRptEntryGet(). saHpiEventGet()
>> always
>> >> > returns SA_ERR_HPI_TIMEOUT, indicating no events are available to
>> >> read.
>> >> > saHpiRptEntryGet() returns SA_ERR_HPI_NOT_PRESENT indicating that
>> no
>> >> RPT
>> >> > entries are present.
>> >> >
>> >> > After some time (30 seconds to a minute), saHpiEventGet()
>> continues
>> >> to
>> >> > return SA_ERR_HPI_TIMEOUT - still no events - but,
>> saHpiRptEntryGet()
>> >> > now returns the first RPT entry, and I can walk through the entire
>> >> table.
>> >> >
>> >> > Thus, all those RPT entries seem to have been added to the table,
>> >> while
>> >> > the session was open and subscribed, but no events were received.
>> >> >
>> >> > If I call saHpiDiscover() just after the successful
>> >> saHpiSessionOpen()
>> >> > return, it blocks for that 30 seconds to a minute. Calling
>> >> > saHpiRptEntryGet() just after it returns, I see that the RPT table
>> is
>> >> > filled.
>> >> >
>> >> > David
>> >> >
>> >> > From: shyamala openhpi [mailto:[email protected]]
>> >> > Sent: Wednesday, October 05, 2011 7:34 AM
>> >> > To: [email protected]
>> >> > Subject: Re: [Openhpi-devel] saHpiDiscover() Required?
>> >> >
>> >> > Hi David,
>> >> >
>> >> > Hot-swap or resource-added events will be received if we subscribe
>> >> for
>> >> > the events before starting the openhpid daemon.
>> >> >
>> >> > Regards,
>> >> > Shyamala
>> >> > On Wed, Oct 5, 2011 at 1:34 AM, David McKinley
>> >> > <[email protected]<mailto:[email protected]>> wrote:
>> >> > Hello,
>> >> >
>> >> > I have just seen a problem with OpenHPI that I thought was fixed
>> >> years
>> >> > ago.
>> >> >
>> >> > I started up the openhpi daemon as well as a client program. For
>> a
>> >> > while, as the daemon was reading SDRs and such, I could not open a
>> >> > session. After a while, though, I could. When the session was
>> open,
>> >> I
>> >> > subscribed to receive events, and then tried to access the RPT and
>> >> found
>> >> > it empty. A while later - after more reading of SDRs, FRU data,
>> >> SELs,
>> >> > etc. by the daemon, I checked the RPT again, and it was now
>> >> populated.
>> >> >
>> >> >>>> But no hot-swap or resource-added events were received by the
>> open
>> >> >>>> session!!! <<<
>> >> >
>> >> > This would seem to be very bad behavior for an HPI implementation.
>> >> If a
>> >> > user can have a session open, the RPT and RDR tables should never
>> >> change
>> >> > without events being issued.
>> >> >
>> >> > It seems I can work around this problem by calling saHpiDiscover()
>> >> > immediately after opening a session, but according to the HPI
>> >> > specification this is explicitly not required. Is this a known
>> bug
>> >> in
>> >> > OpenHPI?
>> >> >
>> >> > Thanks,
>> >> >
>> >> > David
>> >> >
>> >> > ------------------------------------------------------------------
>> ---
>> >> ---------
>> >> > All the data continuously generated in your IT infrastructure
>> >> contains a
>> >> > definitive record of customers, application performance, security
>> >> > threats, fraudulent activity and more. Splunk takes this data and
>> >> makes
>> >> > sense of it. Business sense. IT sense. Common sense.
>> >> > http://p.sf.net/sfu/splunk-d2dcopy1
>> >> > _______________________________________________
>> >> > Openhpi-devel mailing list
>> >> > [email protected]<mailto:Openhpi-
>> >> [email protected]>
>> >> > https://lists.sourceforge.net/lists/listinfo/openhpi-devel
>> >
>> > ---------------------------------------------------------------------
>> ---------
>> > All of the data generated in your IT infrastructure is seriously
>> > valuable.
>> > Why? It contains a definitive record of application performance,
>> security
>> > threats, fraudulent activity, and more. Splunk takes this data and
>> makes
>> > sense of it. IT sense. And common sense.
>> > http://p.sf.net/sfu/splunk-d2dcopy2
>> > _______________________________________________
>> > Openhpi-devel mailing list
>> > [email protected]
>> > https://lists.sourceforge.net/lists/listinfo/openhpi-devel
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously
> valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Openhpi-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
