Re: [Freeipmi-devel] Sensors incorrect assumption about discrete sensors

[Albert Chu]

ahh, I understand what you were trying to do now.  I'll change the
function back to the way it was.  I'll re-write my host monitoring code
to use my own "sensor_classify" function.

Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratory

----- Original Message -----
From: Anand Babu <address@hidden>
Date: Monday, March 29, 2004 5:24 pm
Subject: Re: [Freeipmi-devel] Sensors incorrect assumption about
discrete sensors

> 
> Original code was correct.
> 
> "Generic - discrete sensor" and "Sensor Specific - discrete sensors"
> are different.
> 
> Original code classified event-reading based on 36.1.
> 
> When event/reading type code is between 0x01 to 0x0C, you have to 
> sub switch-case using table 36.2.
> 
> It was confusing because of the MACRO names.
> We should rename them as
> IPMI_SENSOR_CLASS_DIGITAL_DISCRETE =>
>    IPMI_SENSOR_CLASS_GENERIC_DISCRETE
> IPMI_SENSOR_CLASS_DISCRETE =>
>    IPMI_SENSOR_CLASS_SENSOR_SPECIFIC_DISCRETE.
> 
> Happy Hacking,
> -ab
> 
> ,----[ Albert Chu <address@hidden> ]
> | It seems my "fix" of ipmi_sensor_classify was only half a fix.  
> Fish's| sensors code incorrectly assumes that a "discrete sensor" 
> has an
> | event/reading type code of 0x6Fh.  Thus, it always interprets states
> | based on the the sensor specific data (table 36-3 of the IPMI spec).
> | Instead it should check the event/reading type code first, to make
> | sure it is 0x6Fh.  If it isn't 0x6F, then it should be using the
> | generic sensor data (table 36-2).
> | 
> | I think this only affects 1 sensor, Power Unit Redund, on Tiger4. 
> So
> | I'm not too hung up delaying Alpha5-Qa1 for this bug.  But I 
> think its
> | something that should be fixed soon.
> | 
> | Al
> `----
> 
> ----- Original Message -----
> From: Albert Chu <address@hidden>
> Date: Friday, March 26, 2004 2:53 pm
> Subject: [Freeipmi-devel] Couple of major changes ...
> 
> > Made a few changes that are pretty significant that I thought I 
> should> mention.
> > 
> > unassemble_ipmi_kcs_pkt:  similar to ipmi_lan_pkt, there is no 
> > guaranteethat the packet returned from ipmi_kcs_read will be 
> > atleast the size
> > of tmpl_hdr_kcs + tmpl_cmd.  In particular, if comp_code != 
> > success, the
> > package may be much smaller.  So we cannot just error out if the 
> > packetis smaller than we expect.
> > 
> > tmpl_get_sensor_threshold_reading_rs: Removed the "reserved3" 
> > field. 
> > This field is optionally returned from the BMC.  On tiger4, it is 
> not> returned at all.  On those machines that it is returned,
> > unassemble_ipmi_kcs_pkt will ensure it isn't copied at all to the
> > obj_cmd buffer.
> > 
> > ipmi_sensor_classify: This function returned incorrect classes on 
> some> event type codes, leading to some incorrect output in 
> sensors.  As far
> > as I can tell, this did not break anything, although there was a 
> > chanceit could have.
> > 
> > Al
> 
> 
> -- 
> _.|_ 
> (_||_)
> Free as in Freedom <www.gnu.org>
>