Ah, ok, I didn't spend enough time reading your email.
The OEM designation doesn't matter that much, if it's a generic discrete
sensor the reading names should still work.
I've looked at the code, the spec, and several machines I have. The
code appears to be working as intended and in compliance with the spec.
However, I've noticed something weird.
On one machine, the generic discrete sensors all return zero for all
bits. This is invalid, if you have an "asserted" and "deasserted"
state, one of them should be set. Here's how I looked at it in openipmish:
> sensor info 'l(7.1).Proc Missing0'
Sensor
Name: l(7.1).Proc Missing0
LUN: 0
Number: 128
Event Reading Type: 3
Event Reading Type Name: discrete_state
Type: 21
Type Name: module_board
Event Support: entire sensor
Init Scanning: true
Init Events: true
Init Thresholds: false
Init Hysteresis: false
Init Type: true
Init Power Up Events: true
Init Power Up Scanning: true
Ignore If No Entity: false
Auto Rearm: true
OEM1: 0
Id: Proc Missing0
Event
Offset: 0
Name: state deasserted
Supports: assertion
Event
Offset: 1
Name: state asserted
Supports: assertion
> debug msg on
Debugging set
> sensor get 'l(7.1).Proc Missing0'
DEBG: l 0 outgoing msgid=00586f00
addr = 0c 00 00 00 0f 00 00 00
msg = netfn=s/e(c):04 cmd=GetSensReading:2d data_len=1.
data =
80
> DEBG: l 0 incoming msgid=00586f00
addr = 0c 00 00 00 0f 00 00 00
msg = netfn=s/e(r):05 cmd=GetSensReading:2d data_len=5. cc=Normal:00
data =
00 00 c0 00 00
Sensor
Name: l(7.1).Proc Missing0
Event Messages Enabled: true
Sensor Scanning Enabled: true
Initial Update In Progress: false
Event
Offset: 0
Name: state deasserted
Set: false
Event
Offset: 1
Name: state asserted
Set: false
>debug msg off
Now for ipmitool:
Proc Missing | 80h | ok | 7.1 |
Both of the bits are not set, and ipmitool shows them not there. They
are not in the message, so this is being done correctly. On another
machine, it seems to be working as the SPEC says. Here's the output
from openipmish:
> sensor info 't(7.1).CPU Therm Ctrl0'
Sensor
Name: t(7.1).CPU Therm Ctrl0
LUN: 0
Number: 192
Event Reading Type: 3
Event Reading Type Name: discrete_state
Type: 1
Type Name: temperature
Event Support: entire sensor
Init Scanning: true
Init Events: true
Init Thresholds: false
Init Hysteresis: false
Init Type: true
Init Power Up Events: true
Init Power Up Scanning: true
Ignore If No Entity: true
Auto Rearm: true
OEM1: 0
Id: CPU Therm Ctrl0
Event
Offset: 0
Name: state deasserted
Event
Offset: 1
Name: state asserted
Supports: assertion
Supports: deassertion
> debug msg on
Debugging set
> sensor get 't(7.1).CPU Therm Ctrl0'
DEBG: t 0 outgoing msg to IPMI addr = 01 00 00 00 00 00 20 00
msg = netfn=s/e(c):04 cmd=GetSensReading:2d data_len=1
data(len=1.) =
c0
> DEBG: incoming msg from IPMB addr = 0c 00 00 00 0f 00 00 00
msg = netfn=s/e(r):05 cmd=GetSensReading:2d data_len=5. cc=Normal:00
data =
00 00 c0 01 00
Sensor
Name: t(7.1).CPU Therm Ctrl0
Event Messages Enabled: true
Sensor Scanning Enabled: true
Initial Update In Progress: false
Event
Offset: 0
Name: state deasserted
Set: true
Event
Offset: 1
Name: state asserted
Set: false
and ipmitool:
CPU Therm Ctrl | C0h | ok | 7.1 | State Deasserted
The bit is set properly in both places.
What versions of ipmitool and OpenIPMI are you using? Can you try using
openipmish to see if it works there?
-corey
[EMAIL PROTECTED] wrote:
> I have already attempted using ipmi_sensor_get_states(). It is not
> finding any states at all (please re-read the initial message, second
> paragraph). Ipmitool finds states for these sensors so something is not
> quite right. These sensors are in fact OEM; is there a different set of
> state functions that I need to use for OEM?
>
> Thanks again,
> Jen
>
> -----Original Message-----
> From: Corey Minyard [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 26, 2007 5:16 PM
> To: Vanderputten, Jennifer
> Cc: openipmi-developer@lists.sourceforge.net
> Subject: Re: [Openipmi-developer] Discrete sensor states
>
> See the function read_sensor_states() in cmdlang/cmd_sensor.c. It gets
> a reading and iterates through it. You really shouldn't be directly
> using ipmi_get_reading_name(), you should use
> ipmi_sensor_reading_name_string(). If there are OEM plugins that modify
>
> these values, they may not exactly match up with
> ipmi_get_reading_name(), or may have values that are OEM-specific.
>
> You need to use ipmi_sensor_get_states() to get the current state
> values. ipmi_sensor_get_event_enables() tells you if a specific sensor
> is enabled to send an event when the specific offset changes. And being
>
> both set, you will get an event if either bit changes :-).
>
> -corey
>
> [EMAIL PROTECTED] wrote:
>
>> 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
>> Openipmi-developer@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openipmi-developer
>>
>>
>
>
>
> -------------------------------------------------------------------------
> 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
> Openipmi-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openipmi-developer
>
-------------------------------------------------------------------------
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
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
