On Fri, Dec 25, 2015 at 11:47:19AM +0900, Masao Uebayashi wrote:
> On Tue, Dec 22, 2015 at 09:03:56PM +1000, Jonathan Matthew wrote:
> > On Tue, Dec 22, 2015 at 06:42:23PM +0900, Masao Uebayashi wrote:
> > > On Mon, Dec 21, 2015 at 03:53:09PM +0100, Mark Kettenis wrote:
> > > > > Date: Mon, 21 Dec 2015 22:47:19 +0900
> > > > > From: Masao Uebayashi <uebay...@tombiinc.com>
> > After I looked at the ipmitool code and discovered it just uses the reported
> > sensor status rather than doing threshold checks itself, I changed ipmi(4)
> > to
> > match and then all the sensors were OK, except when things were genuinely
> > wrong.
> >
> > Is there a reason we should do the threshold checks rather than just looking
> > at the status reported right next to the sensor reading?
>
> According to Rev. 1.3 of ipmi.c:
>
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ipmi.c?rev=1.3&content-type=text/x-cvsweb-markup
>
> > * Fixed threshold values
> > Bits in Sensor reading did not contain correct values for threshold
> > vioation; must compare reading against actual threshold.
>
> ... which sounds like the opposite of what you are saying.
>
> Without learning much about sensor part of IPMI, I think that both reading
> bits and "Get Sensor Thresholds Command" work. I also think that following
> what ipmitool is a safer bet.
OK, now I have really read the sensor part of the spec, and now I understand:
"Get Sensor Thresholds Command" is to retrieve the threshold values against
which sensor values (e.g. fan speed) are comapred. In other words, this
command returns those configured values, regardless of the current sensor
values.
So the current code is completely wrong and Jonathan's diff is correct.
Threshold values will be configured by ipmitool from userland via /dev/ipmi*.
In-kernel ipmi(4) driver only checks the state via reading ("Get Sensor
Reading Command") and reports the result to sensors(9).
