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

[Albert Chu]

>   I think, better way to classify sensor is, by Table 36-1.   

Classifying either way is fine.  I just think the variable
names/function names need to be re-worded.  The IPMI spec lists the
following definitions in Section 36.1:

Discrete

Multiple states possible. Discrete sensors can contain up to 15 possible
states. For discrete sensors, the Get Sensor Reading command returns a
bit field where each bit reflects a different state. It is possible for
a discrete sensor to have more than one state active at a time.

Digital Discrete

A digital sensor is not really a unique class, but a term commonly used
to refer to special case of a discrete sensor that only has two possible
states.

So classifying with the names "digital discrete" and "discrete" is
confusing.  

Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratory

----- Original Message -----
From: address@hidden
Date: Monday, March 29, 2004 8:07 pm
Subject: Re: [Freeipmi-devel] Sensors incorrect assumption about
discrete sensors

> Hi Al
>   In table 36-2, status for a Event/Reading Type Code has multiple 
> status. 
> When we do sensor reading, BMC returns only single status for a 
> sensor,whose Event/Reading Type Code is Generic Discrete.
> 
>   I think, better way to classify sensor is, by Table 36-1.   
> Otherwise, we
> need to put decision making in discrete sensors to handle sensors, 
> whoseEvent/Reading Type Code is in Table 36-2.
> 
> Thanks
> Bala
> 
> 
> > > Why do you want to write your own sensors_classify function?, 
> > 
> > I simply divide up my code into functions differently than fish.  
> You> divide up your fish code into:
> > 
> > "threshold"
> > "generic discrete"
> > "sensor specific discrete"
> > 
> > functions.  I divided up my functions into:
> > 
> > "threshold"
> > "digital discrete sensors"
> > "non-digital discrete discrete sensors"
> > 
> > That's all.
> > 
> > > If we have to fix it, we can extend to one more classify 
> function 
> > > inside libfreeipmi itself.
> > 
> > How about after Alpha5-Qa1, we do this.  I think first, we maybe 
> need to
> > re-word some of the macros names and function names.  That's why I
> > thought ipmi_sensor_classify() as well as the fish functions had 
> those> bugs.
> > 
> > Al
> > 
> > --
> > Albert Chu
> > address@hidden
> > Lawrence Livermore National Laboratory
> > 
> > ----- Original Message -----
> > From: Anand Babu <address@hidden>
> > Date: Monday, March 29, 2004 6:04 pm
> > Subject: Re: [Freeipmi-devel] Sensors incorrect assumption about
> > discrete sensors
> > 
> > > I think both monitoring agent and fish should use common code 
> base as
> > > much as possible.
> > > 
> > > Why do you want to write your own sensors_classify function?, 
> If we
> > > have to fix it, we can extend to one more classify function inside
> > > libfreeipmi itself.
> > > 
> > > -ab
> > > ,----[ Albert Chu <address@hidden> ]
> > > | 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>
> > > > 
> > > 
> > > 
> > > -- 
> > > _.|_ 
> > > (_||_)
> > > Free as in Freedom <www.gnu.org>
> > > 
> > 
> > 
> > 
> > _______________________________________________
> > Freeipmi-devel mailing list
> > address@hidden
> > http://mail.nongnu.org/mailman/listinfo/freeipmi-devel
> > 
> 
> -- 
> +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter 
> Virenschutz +++
> 100% Virenerkennung nach Wildlist. Infos: 
> http://www.gmx.net/virenschutz
>