I am currently using OpenIPMI to discover sensors and get their current
readings. So far I have been successful in implementing for threshold sensors
and for discrete sensors of type "sensor-specific". However, for the other
discrete sensors, I noticed that ipmitool can see additional information that I
am not seeing. For example:
SMI Timeout | 85h | ok | 7.1 | State Deasserted
I can see that this description ("state deasserted") is equivalent to the
descriptions found in OpenIPMI's event_reading_states array, which is acquired
by ipmi_get_reading_name(). However, I do not seem to understand how one
acquires the necessary offset. I have tried using the state event mechanisms
(ipmi_sensor_get_event_enables(), where the callback function does a two-nested
loop through direction and offsets), but this does not seem to yield up what
I'm looking for. Again, given the above example, ipmi_is_discrete_event_set()
tells me that event offset 1 is set for both asserted and deasserted. That
offset maps to "State asserted", which is incorrect. I should be finding event
offset 0 to be set in order to map to the correct description via
ipmi_get_reading_name(). Is this a bug or am I simply not doing this correctly?
I have also attempted using ipmi_sensor_get_states() and ipmi_is_state_set(),
but those functions only seem to work for discrete sensors of type
"sensor-specific". For the other discrete sensors, ipmi_is_state_set() always
indicates that there are no states set at all. Thus I assumed that these
functions are only used for sensor-specific types.
--Jen
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Openipmi-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
