Hi,
Sorry for the unclear description of the patch sent in my last email. I will
clarify it clearly here.
I think the function "process_resource_event()" in src/event.c may has a
bug.
My understanding for the variable "exists" is to tell whether the resource
has been added to the daemon or not.
But the plugin "ipmi" may push several events (all of SAHPI_ET_HOTSWAP
type). In my case, the first HOTSWAP event with status PRESENCE, so the
resource will be added, but the RDR list of this event has nothing. And
then, another HOTSWAP event came, this time the RDR list contains the RDRs
detected. But since the resource has already been added, the variable
"exists" is not NULL now, then the RDRs couldn't be added this time. So I
can't dump these RDRs with command "hpitree".
I have check the function "oh_add_rdr()", it will add the RDR if it's not
found, and update the RDR if it's found. So I think the function already has
the "update" feature. I think we can remove the checking of "exist" without
causing problem.
My second question is do you know when the code for
"SAHPI_RESE_RESOURCE_UPDATED" will be added to the daemon?
Since I'm working on a project using openhpi as the data collector, and this
problem has blocked the project's development. It will be very helpful if
you can help me.
Thanks a lot!
static int process_resource_event(struct oh_domain *d, struct oh_event *e)
{
RPTable *rpt = NULL;
SaHpiRptEntryT *exists = NULL;
unsigned int *hidp = NULL;
SaErrorT error = SA_OK;
SaHpiResourceEventTypeT *retype = NULL;
SaHpiHsStateT state = SAHPI_HS_STATE_NOT_PRESENT;
SaHpiBoolT process_hpi = TRUE;
if (!d || !e) return -1;
rpt = &(d->rpt);
exists = oh_get_resource_by_id(rpt, e->resource.ResourceId);
if (e->event.EventType == SAHPI_ET_RESOURCE) {
retype =
&e->event.EventDataUnion.ResourceEvent.ResourceEventType;
if (*retype != SAHPI_RESE_RESOURCE_FAILURE) {
/* If previously failed, set EventT to RESTORED */
if (exists && exists->ResourceFailed) {
*retype = SAHPI_RESE_RESOURCE_RESTORED;
} else if (exists &&
!exists->ResourceFailed) {
process_hpi = FALSE;
}
e->resource.ResourceFailed = SAHPI_FALSE;
} else {
e->resource.ResourceFailed = SAHPI_TRUE;
}
} else if (e->event.EventType == SAHPI_ET_HOTSWAP) {
state = e->event.EventDataUnion.HotSwapEvent.HotSwapState;
if (state == SAHPI_HS_STATE_NOT_PRESENT) {
oh_remove_resource(rpt, e->resource.ResourceId);
}
} else {
err("Expected a resource or hotswap event.");
return -1;
}
if (e->event.EventType == SAHPI_ET_RESOURCE ||
(e->event.EventType == SAHPI_ET_HOTSWAP &&
state != SAHPI_HS_STATE_NOT_PRESENT)) {
hidp = g_malloc0(sizeof(unsigned int));
*hidp = e->hid;
error = oh_add_resource(rpt, &e->resource,
hidp, FREE_RPT_DATA);
if (error == SA_OK && !exists) { <--------------- remove
the check here, "if (error == SA_OK) { " is enough.
GSList *node = NULL;
for (node = e->rdrs; node; node = node->next) {
SaHpiRdrT *rdr = (SaHpiRdrT *)node->data;
oh_add_rdr(rpt, e->resource.ResourceId,
rdr, NULL, 0);
}
}
}
if (process_hpi) process_hpi_event(d, e);
return 0;
}
2009/8/18 Anton Pak <[email protected]>
> Well,
>
> For our plug-in we used HotSwap event (State X -> State X) for
> adding/removing RDRs.
> However with HPI B.03 one has no need for such tricks.
> Resource event SAHPI_RESE_RESOURCE_UPDATED should be used.
> The only thing I am concerned it was not yes implemented in OpenHPI.
>
> Anton Pak
>
>
> On Tue, 18 Aug 2009 13:29:20 +0400, singleye <[email protected]>
> wrote:
>
> Hi Anton,
>> Thanks for your feedback!
>> Yes, I've looked into the daemon's code. It's like what you said.
>> Probably the ipmi plugin need to be enhanced.
>> And I have a patch for openhpid/event.c. I think this may also be
>> another solution for this problem. What do you think?
>>
>> --- 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;
>>
>>
>> 2009/8/14 Anton Pak <[email protected]>
>>
>>>
>>> Hello!
>>>
>>> My understanding is:
>>>
>>> SAHPI_ET_RESOURCE events(Resource Added/Resource Removed) are emitted
>>> only by resources without FRU and HS capabilities.
>>> Resources with FRU capability emit SAHPI_ET_HOTSWAP events(Not Present ->
>>> Active, Active -> Not Present).
>>> Resources with FRU and HS capabilities emit SAHPI_ET_HOTSWAP events of
>>> any kind.
>>>
>>> Anton Pak
>>>
>>>
>>> On Fri, 14 Aug 2009 13:04:48 +0400, 王强 <[email protected]> wrote:
>>>
>>> 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
