net...@precedence.co.uk (Stephen Borrill) writes:
> Current CritMax WarnMax WarnMin CritMin Unit
>[ipmi0]
>11-LOM-CORE:59.2530.000 110.471degC
>Seen on 9.3_STABLE, but also in 10 BETA.
>I suppose one simple fix would be to ensure that if CritMax is lower
>than WarnMax, it should be set to the value of WarnMax.
IPMI reports 3 upper and 3 lower limits (each as an unsigned byte)
and a bitmask to show which value is valid.
lower non-recoverable threshold
-> configures CritMin
lower critical threshold
-> configures CritMin
lower non-critical threshold
-> configures WarnMin
lower limits of 0 are ignored, because you cannot exceed them.
upper non-recoverable threshold
-> configures CritMax
upper critical threshold
-> configures CritMax
upper non-critical threshold
-> configures WarnMax
upper limits of 255 are ignored, because you cannot exceed them.
Apparently your system says that the upper critical or the
non-recoverable threshold exist but returns a value of zero.
The code could do some more sanity checking and then just
skip the invalid limits.
Something like:
@@ -1582,6 +1684,16 @@ ipmi_get_sensor_limits(struct ipmi_softc
break;
}
+ if ((data[0] & 0x28) == 0x28 && data[6] < data[4])
+ data[0] ^= 0x20;
+ if ((data[0] & 0x18) == 0x18 && data[5] < data[4])
+ data[0] ^= 0x10;
+
+ if ((data[0] & 0x0a) == 0x0a && data[3] > data[1])
+ data[0] ^= 0x08;
+ if ((data[0] & 0x06) == 0x06 && data[2] > data[1])
+ data[0] ^= 0x04;
+
if (data[0] & 0x20 && data[6] != 0xff) {
*pcritmax = ipmi_convert_sensor([6], psensor);
*props |= prop_critmax;
As an alternative you could also override the limit in /etc/envsys.conf.
