Hey Jim,
On Wed, 2012-02-22 at 04:58 -0800, Jim Mankovich wrote:
> Al,
>
> I interpreted the ** statement as meaning the 8 bit "Sensor Units 1" field
> should
> be written with zero since the ** statement identifies the entire 8 bit
> value, 00h, not
> a 2 bit value 00b. But, given that the ** is next to "Analog (numeric)
> Data Format" it
> would seem to only apply to this 2 bit field within the 8 bit "Sensor Units
> 1" field.
>
> "** Specifies threshold and 'analog' reading, if 'analog' reading provided.
> If neither
> thresholds nor analog reading are provided, this field should be written as
> 00h."
>
> In the cases where you saw 00b in the Analog (numeric) Data Format field, was
> the value of the entire "Sensor Unit 1" field zero? An entire 8 bit field
> of zero would
> seem to make sense for a Discrete sensor.
Yes, but an entire 8 bit field of zero for "Sensor Unit 1" would also
make sense for an discrete sensor w/ an analog reading. Which is why I
think your original interpretation was not safe.
I'd have to think about this a tad more, but perhaps using sensor_unit_2
and sensor_unit_3 in combination might make some of the guesses more
valid. Here's a guess:
if ((sensor_unit_1 & 0xC0) == 0xC0
|| (sensor_unit_1 == 0
&& sensor_unit_2 == 0
&& sensor_unit_3 == 0))
/* assume discrete sensor w/ no analog reading */
else
/* assume an analog reading */
Al
> -- Jim Mankovich |jm...@hp.com --
>
>
> On 2/21/2012 4:26 PM, Albert Chu wrote:
> > Hi Jim,
> >
> > On Tue, 2012-02-21 at 15:02 -0800, Jim Mankovich wrote:
> >> Al,
> >>
> >> My interpretation was that 11b means discrete and all other values are
> >> analog.
> > But doesn't this interpretation contradict "If neither thresholds nor
> > analog reading are provided, this field should be written as 00h."?
> >
> > The point is, how many motherboards/sensors might be incorrectly
> > affected by this change? When I posted my original post, I decided to
> > look at a few of the motherboards we had here. A fair number of them
> > have 00b for discrete sensors that don't return an analog reading.
> >
> > Al
> >
> >> I interpreted it this way because 11b is explicit in stating "Does not
> >> return
> >> analog (numeric) reading" (11b == Discrete) . For Compact Sensors 11b is
> >> the
> >> only valid data format because Compact Sensors can only be used for
> >> discrete (per
> >> the table at the beginning of Section 43.1 which specifies that only full
> >> records
> >> can support analog readings). If anything other than 11b were Discrete,
> >> these
> >> values would need to be identified as valid in the Compact "Sensor Units
> >> 1" Field.
> >>
> >> 11b Discrete, all other values Analog
> >>
> >> -- Jim Mankovich |jm...@hp.com --
> >>
> >>
> >> On 2/21/2012 3:23 PM, Albert Chu wrote:
> >>> Hey Jim,
> >>>
> >>>> I don't see why ipmtool shouldn't rely on the "analog data format"
> >>>> being set correctly instead of making assumptions.
> >>> Generally speaking, the spec isn't clear on this part (atleast in the
> >>> version I have most recently downloaded). From 43-1 in the spec:
> >>>
> >>> ----
> >>>
> >>> [7:6] - Analog (numeric) Data Format**
> >>> 00b = unsigned
> >>> 01b = 1’s complement (signed)
> >>> 10b = 2’s complement (signed)
> >>> 11b = Does not return analog (numeric) reading
> >>>
> >>> ** Specifies threshold and ‘analog’ reading, if ‘analog’ reading
> >>> provided. If neither thresholds nor analog reading are provided, this
> >>> field should be written as 00h.
> >>>
> >>> ----
> >>>
> >>> So if this field is listed as "00b", is the sensor reading an analog
> >>> "unsigned" reading? Or is it "neither threshold nor analog reading are
> >>> provided"? How do I know which?
> >>>
> >>> Al
> >>>
> >>> On Tue, 2012-02-21 at 12:48 -0800, Jim Mank wrote:
> >>>> Al,
> >>>>
> >>>> My email is directly related to your thread, but there are more issues
> >>>> with incorrect
> >>>> interpretation than you identified. The "event/reading type code"
> >>>> must be used
> >>>> to identify a Threshold vrs a Discrete sensor and the "analog data
> >>>> format" flag should
> >>>> be used to identify analog vrs discrete units. I agree that having a
> >>>> discrete sensor
> >>>> return an analog reading "makes no sense", but I don't see why ipmtool
> >>>> shouldn't
> >>>> rely on the "analog data format" being set correctly instead of making
> >>>> assumptions.
> >>>>
> >>>> -- Jim Mankovich |jm...@hp.com --
> >>>>
> >>>>
> >>>> On 2/21/2012 12:57 PM, Albert Chu wrote:
> >>>>> I suppose this is now related to this thread I started awhile back due
> >>>>> to something I found on an HP machine.
> >>>>>
> >>>>> http://www.mail-archive.com/ipmitool-devel@lists.sourceforge.net/msg01654.html
> >>>>>
> >>>>>> The IPMI Specification is not clear if a discrete sensor can return
> >>>>>> units.
> >>>>> Agreed that it does not appear to be illegal, however to me, a discrete
> >>>>> sensor that returns an analog reading "makes no sense". Here are some
> >>>>> sensors on an HP machine that had a discrete event type but an analog
> >>>>> reading (I'm using FreeIPMI's output):
> >>>>>
> >>>>> 6 | Power Supply 1 | Power Supply | 1200.00 | W | 'Presence detected'
> >>>>>
> >>>>> 10 | Fan 5 | Fan | 76.83 | % | 'transition to Running'
> >>>>>
> >>>>> is 1200W/76.83% high? low? normal?
> >>>>>
> >>>>> Al
> >>>>>
> >>>>>
> >>>>> On Tue, 2012-02-21 at 11:17 -0800, Schoeller, Patrick (iLO - Houston,
> >>>>> TX) wrote:
> >>>>>> The IPMI Specification is not clear if a discrete sensor can return
> >>>>>> units. I think the Event Reading Code is really the key indicator if
> >>>>>> this is a threshold sensor or a discrete sensor. For the Discrete
> >>>>>> Sensor, the value could be anything. Again, the IPMI Specification has
> >>>>>> never clarified this and I agree with Jim that the Event Reading Code
> >>>>>> should be the determining factor.
> >>>>>>
> >>>>>> HP ProLiant servers do return a value in the data field of the "Get
> >>>>>> Sensor Reading" command on some discrete sensors. But the "Reading
> >>>>>> Mask" are set correctly for the Event Reading Code. The "ipmitool"
> >>>>>> application, however, sees a non-zero value and tries to use the
> >>>>>> "Threshold Reading Mask" bits.
> >>>>>>
> >>>>>> A patch for this had been submitted upstream by Dann Frazier a couple
> >>>>>> years ago. Not sure where it went.
> >>>>>>
> >>>>>> Pat
> >>>>>>
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Albert Chu [mailto:ch...@llnl.gov]
> >>>>>> Sent: Tuesday, February 21, 2012 13:12
> >>>>>> To: Mankovich, Jim
> >>>>>> Cc:ipmitool-devel@lists.sourceforge.net
> >>>>>> Subject: Re: [Ipmitool-devel] Sensor display logic issues
> >>>>>>
> >>>>>> Hi Jim,
> >>>>>>
> >>>>>> On Tue, 2012-02-21 at 10:03 -0800, Jim Mank wrote:
> >>>>>>> All,
> >>>>>>>
> >>>>>>> I've been looking a incorrect sensor display issues with the ipmitool
> >>>>>>> that I would like
> >>>>>>> to get some feedback on before proposing a specific solution.
> >>>>>>> 1. ipmitool does not properly decode discrete vrs analog
> >>>>>>> units
> >>>>>>> in all cases
> >>>>>>> 2. ipmitool does not correctly identify the Threshold Sensor
> >>>>>>> class for Compact and
> >>>>>>> Full sensors.
> >>>>>>> For #1, the IPMI spec states that the sensor units are identified in
> >>>>>>> the Full and Compact
> >>>>>>> SDR by the setting in the "Sensor Units 1" Field bits [7:6] "Analog
> >>>>>>> (numeric) Data Format".
> >>>>>>> See the "Sensor Units 1" Field description on pages 522 and 528 of the
> >>>>>>> latest IPMI spec.
> >>>>>>> The "Sensor Units 1" Field bits [7:6] field is not used in all cases
> >>>>>>> by the ipmitool to determine
> >>>>>>> discrete vrs analog sensor units.
> >>>>>> Discrete sensors technically shouldn't have units. Do you mean that
> >>>>>> sensors are being mis-interpreted as discrete when they should be
> >>>>>> analog? Or vice versa?
> >>>>>>
> >>>>>> Al
> >>>>>>
> >>>>>>> For #2, both the Full and Compact SDR field "Event/Reading Type Code"
> >>>>>>> field identifies
> >>>>>>> whether or not a Event/Reading type is of class Threshold. This
> >>>>>>> field should be used by both
> >>>>>>> the Full and Compact sensor display routines to identify that the
> >>>>>>> given sensor class is of type
> >>>>>>> Threshold. See "Event/Reading Type Code" on pages 519 and 525 of the
> >>>>>>> latest IPMI spec
> >>>>>>> and Table 42-1 and Table 42-2.
> >>>>>>>
> >>>>>>> In working through a possible solutions to the above issues, I started
> >>>>>>> looking in detail at the
> >>>>>>> feasibility of merging ipmi_sdr_print_sensor_compact and
> >>>>>>> ipmi_sdr_print_sensor_full into a
> >>>>>>> single function. In investigating this, I found a dissimilarity in
> >>>>>>> how these two routines treat the
> >>>>>>> global output flags, verbose, csv_verbose and sdr_extended. I
> >>>>>>> believe these two routines
> >>>>>>> should be treating these global output flags in exactly the same way.
> >>>>>>> For example, if you specify
> >>>>>>> both csv_output and verbose (-c -v) , the full print routine will
> >>>>>>> output csv formatted information
> >>>>>>> and use more verbose output for certain fields, but, the compact print
> >>>>>>> routine will not output
> >>>>>>> csv formatted information at all. I think the compact display
> >>>>>>> routine should be changed
> >>>>>>> to interpret these global output flags in exactly the same was as the
> >>>>>>> full display routine does.
> >>>>>>>
> >>>>>>> Here are the main questions I am looking for some feedback on:
> >>>>>>>
> >>>>>>> Is my interpretation of the IPMI spec with regard to #1 and #2
> >>>>>>> consistent with other peoples
> >>>>>>> understandings?
> >>>>>>>
> >>>>>>> Can the compact sensor print routine (ipmi_sdr_print_sensor_compact)
> >>>>>>> be changed to interpret
> >>>>>>> the global output flags in the same way that the full sensor print
> >>>>>>> routine interprets them?
> >>>>>>>
> >>>>>>> Thanks in advance,
> >>>>>>> --
> >>>>>>> -- Jim Mankovich |jm...@hp.com --
> >>>>>> --
> >>>>>> Albert Chu
> >>>>>> ch...@llnl.gov
> >>>>>> Computer Scientist
> >>>>>> High Performance Systems Division
> >>>>>> Lawrence Livermore National Laboratory
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ------------------------------------------------------------------------------
> >>>>>> Keep Your Developer Skills Current with LearnDevNow!
> >>>>>> The most comprehensive online learning library for Microsoft developers
> >>>>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
> >>>>>> MVC3,
> >>>>>> Metro Style Apps, more. Free future releases when you subscribe now!
> >>>>>> http://p.sf.net/sfu/learndevnow-d2d
> >>>>>> _______________________________________________
> >>>>>> Ipmitool-devel mailing list
> >>>>>> Ipmitool-devel@lists.sourceforge.net
> >>>>>> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
> >>>> ------------------------------------------------------------------------------
> >>>> Keep Your Developer Skills Current with LearnDevNow!
> >>>> The most comprehensive online learning library for Microsoft developers
> >>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> >>>> Metro Style Apps, more. Free future releases when you subscribe now!
> >>>> http://p.sf.net/sfu/learndevnow-d2d
> >>>> _______________________________________________
> >>>> Ipmitool-devel mailing list
> >>>> Ipmitool-devel@lists.sourceforge.net
> >>>> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
--
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
