Re: [Openipmi-developer] Discrete sensor states
Brought to you by:
cminyard
From: Corey M. <mi...@ac...> - 2007-07-27 16:14:19
|
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 Van...@em... 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:mi...@ac...] > Sent: Thursday, July 26, 2007 5:16 PM > To: Vanderputten, Jennifer > Cc: ope...@li... > 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 > > Van...@em... 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 >> Ope...@li... >> 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 > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openipmi-developer > |