Hi Andy,
I tried ipmidirect today. I got something like this and it will change
randomly everytime I run hpitree.
Do you have any clue?
Thanks!
# hpitree
hpitree (rev 6571) - This program came with OpenHPI 2.12.0
SAF HPI Version B.02.01
Discovery done
RptEntryGet returns NOT_PRESENT
Entity Path:
{-967228224,32559}{-967222888,32559}{-967227000,32559}{-967229440,32559}{-967224120,32559}{-967225344,32559}{-967218800,32559}{-967220032,32559}{-967221248,32559}{-967215864,32559}{-967152848,32559}{-969300090,32559}{-971564143,32559}{UNSPECIFIED,0}{1434640704,32767}{-967227000,32559}
EntryId: 1434639664
ResourceId: 32767
Resource Information:
Product ID: 7092
Firmware Major Revision: 23
Firmware Minor Revision: 198
Aux Firmware Revision: 47
GUID: 7f000086-a739-c62f-7f00-000100000000
Entity Path:
{-967228224,32559}{-967222888,32559}{-967227000,32559}{-967229440,32559}{-967224120,32559}{-967225344,32559}{-967218800,32559}{-967220032,32559}{-967221248,32559}{-967215864,32559}{-967152848,32559}{-969300090,32559}{-971564143,32559}{UNSPECIFIED,0}{1434640704,32767}{-967227000,32559}
Capabilities:
AGGREGATE_STATUS | CONFIGURATION | FUMI | RESOURCE
HotSwap Capabilities: None
Resource Severity: CRITICAL
ResourceFailed: FALSE
ResourceTag:
Data Type: UNICODE
Language: UNDEF
Data Length: 95
Data: ▒U
This is the configure file section for ipmidirect. I've commented out all
the others.
## Section for ipmidirect plugin using SMI -- local interface
handler libipmidirect {
entity_root = "{SYSTEM_CHASSIS,6}"
name = "smi"
addr = 1
}
This is the device node on the machine.
# ls -l /dev/ipmi0
crw-rw---- 1 root root 248, 0 2009-08-18 03:14 /dev/ipmi0
The ipmidirect plugin.
# ls -l /usr/lib64/openhpi/libipmidirect.*
-rw-r--r-- 1 root root 728764 2009-04-13 02:58
/usr/lib64/openhpi/libipmidirect.a
lrwxrwxrwx 1 root root 23 2009-08-08 06:44
/usr/lib64/openhpi/libipmidirect.so -> libipmidirect.so.2.12.0
lrwxrwxrwx 1 root root 23 2009-08-08 06:44
/usr/lib64/openhpi/libipmidirect.so.2 -> libipmidirect.so.2.12.0
-rwxr-xr-x 1 root root 375408 2009-04-13 02:58
/usr/lib64/openhpi/libipmidirect.so.2.12.0
2009/8/14 Andy Cress <[email protected]>
> 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
> The information contained in this document is CONFIDENTIAL and property of
> Kontron. Any unauthorized review, use, disclosure or distribution is
> prohibited without express written consent of Kontron. If you are not the
> intended recipient, please contact the sender and destroy all copies of the
> original message and enclosed attachments.
>
>
> ------------------------------------------------------------------------------
> 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
>
>
------------------------------------------------------------------------------
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
