net...@precedence.co.uk (Stephen Borrill) writes: > Current CritMax WarnMax WarnMin CritMin Unit >[ipmi0] > 11-LOM-CORE: 59.253 0.000 110.471 degC
>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(&data[6], psensor); *props |= prop_critmax; As an alternative you could also override the limit in /etc/envsys.conf.