I have found that using the ipmidirect plugin is simpler and more reliable.
Have you tried that instead of the ipmi plugin?
Andy
From: 王强 [mailto:[email protected]]
Sent: Friday, August 14, 2009 5:05 AM
To: [email protected]
Subject: [SPAM] - [Openhpi-devel] hpitree can't dump full info on Dell 11G -
Email found in subject
Hi,
I'm using openhpi on Dell 11G. I only config to use the IPMI plugin. But I have
problem while dump the hpitree with hpitree.
Case description:
1. Start openhpid service.
2. Use hpitree to dump the hpi information. We only get very little information
which we can retrieve from the IPMI using IPMI utilities, a lot of sensors
information are lost.
After some research, I found the work flow on my 11G is like this, it’s
simplified just to show the flow clearly.
Flow steps
IPMI plugin for openhpi
Openhpi daemon
IPMI library
1
Ipmi_open()
Register IPMI callback such as:
1. ipmi_entity_add_presence_handler
2. ipmi_entity_add_hot_swap_handler
3. ipmi_entity_add_sensor_update_handler
4. ipmi_entity_add_control_update_handler
5. ipmi_entity_add_fru_update_handler
2
Hot_swap_handler gets called.
This callback will detect the FRUs on the resource and use
oh_evt_queue_push() to push an FRU event to this plugins’s event queue. [Event
type is FRU, status is PRESENCE]
Sensor_update_handler() gets called.
This callback will detect all the sensor RDRs on the resource and put the
RDRs (actually these RDRs are sensors on the resource) on the plugin’s cache.
3
Ipmi_event() gets called.
4
Daemon will harvest the events pushed by plugin.
If the event type is FRU and the status is PRESENCE, then it will create the
corresponding resource.
If the event type is RESOURCE, it will create the corresponding resource.
5
Ipmi_discover() get called
It search the resources cache and use oh_evt_queue_push to push the RDRs
(actually, these RDRs are the sensors) to this plugin’s event queue. [Event
type is FRU, status is PRESENCE]
6
Ipmi_event() gets called.
7
Daemon will harvest the events pushed by the plugin.
If the event type is FRU and the status is PRESENCE, it will find that the
resource has already been added by the above events created by the IPMI
callbacks and skip the adding of the RDRs. So the sensors are not added.
Because the resource (RPT) has many capabilities on it (FRU, SENSOR), both FRU
and SENSOR can activate the adding of the resource (RPT) while harvest the
corresponding event. In our case, the add of FRU is done first, then the add of
sensors are pushed to the event queue. The internal logic of the daemon of
handling the event doesn’t allow to add the sensor RDRs while the resource
(RPT) has been added (by FRU event). That’s why the sensors information are
lost.
I tried 2 way to fix it.
1. Do not allow ohoi_hot_swap_cb() to push event, then during the
ipmi_discovery() to push the event once instead.
2. I changed the src/event.c a little bit as the following:
--- event.c 2008-07-25 13:23:54.000000000 -0400
+++ event.c.new 2009-08-14 00:55:41.000000000 -0400
@@ -295,7 +295,7 @@
*hidp = e->hid;
error = oh_add_resource(rpt, &e->resource,
hidp, FREE_RPT_DATA);
- if (error == SA_OK && !exists) {
+ if (error == SA_OK) {
GSList *node = NULL;
for (node = e->rdrs; node; node = node->next) {
SaHpiRdrT *rdr = (SaHpiRdrT *)node->data;
Both can make it work. But I'm not sure which is appropriate way.
BTW, I'm also curious about the event type SAHPI_ET_RESOURCE and
SAHPI_ET_HOTSWAP, they both can result in adding the corresponding resource
while harvesting the events. Is this the design nature? Why not just allow
SAHPI_ET_RESOURCE to add the resource, and just let the SAHPI_ET_HOTSWAP tell
the daemon when to add/remove it.
Can anyone help me out of this? Thanks a lot!
singleye
2009.08.14
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
