Albert
The analog bit field is infrequently used.
The event/reading type code should be used.

Look at it from the perspective of extending IPMI to use diefferent sensors.
The event/reading type has more options.

I don't know where in the IPMItool they look at the even/reading code but it
may be at a higher layer than where you noticed it using the analog field.
IPMItool does support
AadvancedTCA hot swap sensors and they use the event/reading type.

h...@jblade.com


On Mon, Mar 28, 2011 at 2:54 PM, Albert Chu <ch...@llnl.gov> wrote:

> 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
>
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Reply via email to