Dan,
Jim is correct that in the context of ipmitool a sensor reading is
available.
If It is not ok there was a bus error, IPMC at the IPMB was removed or the
sensor is undergoing initialization. All situations where the sensor
Event1, Event 2 or Event 3 data is unavailable
If you get an ok then you can then process the data according the Compact
or Full sensor record.
Hank Bruning
JBlade
On Fri, Sep 26, 2014 at 7:41 PM, dan farmer <zenf...@gmail.com> wrote:
> Jim -
>
> It may be true that experts know how to interpret the results. But for
> the other 99.999999% of the planet, “ok” means things are going alright,
> that it’s a green check in the box kind of thing. I know the IPMI protocol
> reasonably well and have run the ipmitool on many, many systems, as well
> as written output parsers and read the man page and some of the source
> code,
> but I personally had no idea that OK didn’t mean some sort of all-clear
> A-OK thing. Now obviously you could say I’m not the brightest bulb in the
> box, and I’m certainly not the most detail oriented reader, but at the
> least
> I’m one data point.
>
> I realize that changing a venerable tool that has been encoded in many a
> script and parsed to kingdom come is not something to do lightly, but I’d
> also bet those same parsers display it as a green light or something
> positive rather than the intended meaning.
>
> I don’t think that anyone would suggest that the creators of the tool are
> trying to deceive or fool others with the output, but I’d strongly suggest
> that the Powers That Be reflect on what is actually meant. If you were to
> suggest today that the tool should say “ok” instead of a former value I
> think you’d get laughed at, it’s simply an absurd injustice of information
> dissemination.
>
> dan
>
> On Sep 26, 2014, at 2:23 PM, Jim Mankovich <jm...@hp.com> wrote:
>
> > Al,
> >
> > As you pointed out 'ok' simply means the sensor itself is operational (a
> > reading is available and
> > valid). It is not an interpretation of the "goodness" of the Sensor
> > Reading. This is the way "ok"
> > should be interpreted in this ipmitool output. I would agree that it
> > would be helpful if ipmitool
> > interpreted the status for discrete sensors to provide more information,
> > but right not it does not.
> > If you understand what "ok" means, then there is really no need for
> > 'N/A' as even for non-discrete
> > sensors "ok" does not mean that the returned Sensor Reading is not above
> > or below an alarm
> > threshold. If you want more detailed information about the sensor
> > use, sdr list -c, or sdr list -v.
> >
> > Thanks for the feedback,
> > Jim
> >
> > On 9/26/2014 12:11 PM, Albert Chu wrote:
> >> Hello,
> >>
> >> Once in awhile I get a bug report to FreeIPMI saying, "ipmitool outputs
> >> that a sensor says 'ok', but FreeIPMI outputs that something is wrong
> >> with a sensor."
> >>
> >> After investigation, it appears that ipmitool's output with 'sdr list'
> >> lists 'ok' for many (all?) discrete sensors regardless of the contents
> >> of that reading. As long as the reading is available and valid, it
> >> outputs "ok". For example, here's a power supply sensor I got on a node
> >> here.
> >>
> >> PSU 1 Status | 0x0b | ok
> >>
> >> 0x0b is not good for this sensor, you usually want to see 0x00 or 0x01.
> >> Yet it still says 'ok'.
> >>
> >> In FreeIPMI, it states
> >>
> >> 54 | PSU 1 Status | Power Supply | N/A | N/A | 'Presence detected'
> 'Power Supply Failure detected' 'Power Supply input lost (AC/DC)'
> >>
> >> So there's something wrong w/ this power supply or its atleast worth
> >> investigating for the staff.
> >>
> >> At minimum, the "ok" output appears to confuse some users. At worst,
> >> some users may think the sensor readings are good when they are in fact
> >> not. Perhaps an output of "N/A" would be more appropriate for discrete
> >> sensors in this case?
> >>
> >> Obviously there's a lot of history in this output with ipmitool, but I
> >> thought I'd mention it for discussion.
> >>
> >> Al
> >>
> >>
> >> --
> >> --- Jim Mankovich | jm...@hp.com (US Mountain Time) ---
> >
> >
> ------------------------------------------------------------------------------
> > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Ipmitool-devel mailing list
> > Ipmitool-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Ipmitool-devel mailing list
> Ipmitool-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
>
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
