From: David M. <dmckinley@GOAHEAD.COM> - 2011-10-07 19:23:12
|
Hi Anton, Comments inserted below. Thanks for your inputs! David > -----Original Message----- > From: Anton Pak [mailto:ant...@pi...] > Sent: Friday, October 07, 2011 1:34 PM > To: ope...@li...; David McKinley > Subject: Re: [Openhpi-devel] saHpiDiscover() Required? > > David, > > See my comments below. > > On Fri, 07 Oct 2011 21:02:35 +0400, David McKinley > <dmc...@go...> > 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:ant...@pi...] > >> Sent: Friday, October 07, 2011 11:52 AM > >> To: ope...@li...; 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 > >> <dmc...@go...> > >> 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:shy...@gm...] > >> > Sent: Wednesday, October 05, 2011 7:34 AM > >> > To: ope...@li... > >> > 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 > >> > <dmc...@go...<mailto:dmc...@go...>> 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 > >> > Ope...@li...<mailto:Openhpi- > >> de...@li...> > >> > 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 > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/openhpi-devel |