On Wed, 7 Apr 2010, Brian A. Seklecki wrote:
> I'm a bit confused about the data structures, but I understand
> thresholds for assertion and de-asseration can be programmed
So after digging some more, it would seem that the worst case scenario
is true:
Sensors can be of 'threshold' type (RPMs, degC, etc.) or they can be
'discrete', meaning that they dont have non-critical values, just
a series of boolean states.
There is a concept of a "Sensor Specific Offset" in the "IPMI Platform
Event Trap Format Specification v1.0" which is a series of hex values:
For example, sensor of type "08h" (Power Supply) can have status codes
Power Supply 00h Presence Detected
01h Power Supply Failure Detected
02h Predictive Failure Asserted
These types of status code prefixes seem be common in Event Traps and in
SDR Sensor lists.
For example, with one power supply unlpugged:
PS Redundancy | 0x0 | discrete | 0x0280|
Normally this sould read 0x0180.
For hot swap power supplies installed -> removed from chassis:
Presence | 0x0 | discrete | 0x0180|
--->
Presence | 0x0 | discrete | 0x0280|
It seems like we should be able to toggle sensor status flags for
'discrete' sensors in this fashion.
Until then, I'll re-code the check parse through each sensor type and
regex match common assertion types for critical status.
Meh. Coding. >:}
~BAS
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
