From: Anton P. <ant...@pi...> - 2011-10-07 18:58:34
|
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). > > 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! > 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. 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 |