I guess one more food for thought, is it technically legal for a sensor
reading to have an analog reading (e.g. FAN RPM, CPU temp), and a
non-threshold set of discrete states?  I can't find anything the spec to
say it's illegal.

In 42.1, it does say for threshold sensors, "The Get Sensor Reading
command for a threshold-based sensor contains the present 'analog'
reading for the sensor along in addition to the discrete threshold
comparison status bit field."  It atleast strongly suggests that
event/reading type code = 01h/threshold and an analog reading go hand in
hand.

Al

On Mon, 2011-03-28 at 11:40 -0700, Albert Chu wrote:
> I just had a user report to me that the sensor output in FreeIPMI's
> ipmi-sensors vs. ipmitool was conflicting.  The core cause of the
> discrepancy is it appears ipmitool judges an analog vs. discrete sensor
> by keying off of a sensor's "analog data format" flag.  Such as this
> code in sensors.c
> 
> int
> ipmi_sensor_print_full(struct ipmi_intf *intf,
>                        struct sdr_record_full_sensor *sensor)
> {
>         if (sensor->unit.analog != 3)
>                 return ipmi_sensor_print_full_analog(intf, sensor);
>         else
>                 return ipmi_sensor_print_full_discrete(intf, sensor);
> }
> 
> In contrast, FreeIPMI's keys off the event/reading type code to
> determine an analog vs. discrete sensor (e.g. event-reading-type-code
> 01h = "threshold" and 02h-0Ch/6Fh = "discrete").
> 
> As I'm going through the IPMI spec, I *think* (and I can be debated)
> that the IPMItool approach is wrong.  In table 43-1, it says, "If
> neither thresholds nor analog reading are provided, this field should be
> written 00h", and 00h = "unsigned", 03h = "does not return analog
> (numeric) reading".
> 
> If the event/reading type code != 01h/threshold, but analog-data-format
> = 00h/unsigned, IPMItool will output an invalid/illegal analog reading.
> Also, it appears that if analog-data-format == 3h, IPMItool assumes that
> event-reading-type-code is == 1h. (from ipmi_sensor_print_full_analog(),
> ipmi_sdr_print_sensor_event_status() is called with the numeric_fmt of
> ANALOG_SENSOR).
> 
> In all fairness, I am now debating if there is a bug in FreeIPMI too.
> FreeIPMI does not allow a "discrete only" reading of a threshold sensor.
> If the event/reading type code == 01h/threshold, but analog data format
> = 03h/"no analog reading", I return an error and say I can't read the
> sensor.  It appears IPMItool doesn't suffer this.
> 
> Needless to say, this is just one motherboard that appears to be doing
> something odd/abnormal from the majority of IPMI motherboards out there.
> But it's perhaps worth bringing up for discussion on the right
> approach/legal approach.
> 
> Al
> 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and publish 
your website. http://p.sf.net/sfu/ms-webmatrix-sf
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Reply via email to