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
