[lm-sensors] [PATCH 79/79] hwmon: (it87) Fix vrm value range
khali at linux-fr.org
Wed Jan 25 11:17:24 CET 2012
On Tue, 24 Jan 2012 07:11:27 -0800, Guenter Roeck wrote:
> On Tue, Jan 24, 2012 at 03:50:12AM -0500, Jean Delvare wrote:
> > We could improve this of course, but is it worth it? As documented in
> > Documentation/hwmon/sysfs-interface, changing the vrm value manually
> > should no longer be needed. libsensors does even ignore this attribute
> > completely. And newer hardware tends to no longer use the VID pins at
> > all. Actually hwmon-vid is in a pretty bad shape at the moment at least
> > for all Intel CPUs after Conroe (2007, yeah!) for which we set the VRM
> > to 82 i.e. Pentium II/III. And nobody complained yet as far as I know!
> If it is like me, I always thought it was a chip problem that it displays
> a voltage of 0. There is no warning, so my take is that people simply don't
> realize that the CPU model is not recognized.
There are 3 different problems here.
Problem #1 is the bug in hwmon-vid which causes all unknown Intel
family 6 processors to use VRM 8.2, even though this is wrong on any
Problem #2 is that unknown VRM for a recent CPU will only be notified
to the kernel log, which regular users don't read. Then you indeed get
a cpu0_vid value of 0. That's apparently what you were seeing on your
system. It would certainly be better to _not_ expose the VID value at
all if we don't know how to decode it.
Problem #3 is that most boards no longer have the VID pins routed to
the hardware monitoring chip, because the same information can be
retrieved from MSR and board makers don't want to route 6 to 8 extra
wires from the CPU to the Super-I/O without a good reason. In general
the VID pins can be used for other functions too. But there is not
always an easy way to figure that out, so on most recent systems,
cpu0_vrm will return a bogus value. We can probably fix some of these
cases but not all.
I expect future Super-I/O chips to drop the VID input feature
altogether, which will make the situation better, hopefully.
> > So I'm really not sure if it is worth spending time on. It might make
> > more sense to turn all these vrm attributes read-only (and ultimately
> > kill them altogether.) If we really want to let the user force the vrm
> > value if automatic detection failed, it would probably be better done
> > as a module parameter to hwmon-vid. It is certainly less flexible, but
> > at least we don't have to repeat it in every hwmon driver.
> After looking into it a bit more, I think we should move the vrm attributes
> to hwmon-vid (and fix hwmon-vid).
More information about the lm-sensors