All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] [PATCH 1/2] k8temp warn about errata
Date: Tue, 18 Nov 2008 10:40:52 +0000	[thread overview]
Message-ID: <20081118114052.17f9395b@hyperion.delvare> (raw)
In-Reply-To: <48E3F505.40401@assembler.cz>

Hi Andreas,

On Tue, 18 Nov 2008 10:25:01 +0100, Andreas Herrmann wrote:
> On Mon, Nov 10, 2008 at 10:38:06AM +0100, Jean Delvare wrote:
> > On Sun, 09 Nov 2008 18:27:53 -0700, Jordan Crouse wrote:
> > > Jean Delvare wrote:
> > > > For what it's worth, Jordan Crouse seems to think that blacklisting on
> > > > a per-revision basis may still work.
> > > 
> > > I think it can.  A much larger sample would probably need to be taken to 
> > > be completely sure - but I hope that we'll find that the problem is 
> > > deterministic enough for a blacklist.  I think we would agree that a 
> > > blacklist would be the more user friendly solution.
> > 
> > OK, but then we should probably extend Rudolf's patch to ask users
> > potentially affected by the errata to report to us. The report should
> > include the CPUID information (e.g. contents of /proc/cpuinfo), the
> > output of sensors (or the raw temperature values from sysfs), and
> > whether or not the user thinks the temperature values are correct.
> 
> How do you find out whether your system is affected by this erratum?
> The erratum is: due to inaccuracy of reported temperature (doesn't
> meet a certain accuracy threshold) triggering of HTC/STC feature is
> inaccurate.
> 
> I am just curious how you'd like to determine the accuracy of the
> thermal sensor ... As an example, if the sensor reports 70 degC when
> the true temperature is 65 degC -- is it worth to blacklist it?

If we are 100% certain that this is the case then yes, I would
blacklist it.

The whole point of hardware monitoring is to report accurate values.
Additional software can be used to take actions based on temperature
values, for example fan speed regulation or CPU frequency changes. If
you can't trust the temperature readings then these operations become
dangerous.

That being said, I guess that the example above is essentially
theoretical? Most cases we've seen so far were not off by 5 degrees.
They were plain wrong, with reported temperatures being in the -20 to
+15 degrees C.

> Jordan, do you know more details about the deviation of the reported
> temparature sensor values from the real ones?
> 
> I'd prefer not to blacklist but to keep the warning about potential
> inaccurate temperature values as introduced by Rudolf. I use k8temp on
> my private machines -- Athlon X2 and a Turion X2 (both are revF CPUs
> and thus affected by erratum 141). I admit, this is more or less a
> gimmick but I would miss it (if blacklisted).

Whatever we end up with, we will add a module parameter to let the user
force the driver binding, exactly for advanced users like you. My point
with the blacklist is that we should not report knowingly incorrect
values to the user _by default_, especially given that the k8temp
driver loads automatically. I think it is better to not report anything
by default rather than potentially wrong values. But I also agree that
we must provide a way to bypass the tests, if nothing else, because our
blacklist or heuristic may be incorrect.

Please keep in mind that most end users do not read the kernel logs
(thankfully - they really shouldn't have to.)

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

  parent reply	other threads:[~2008-11-18 10:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-01 22:09 [lm-sensors] [PATCH 1/2] k8temp warn about errata Rudolf Marek
2008-10-25 12:43 ` Jean Delvare
2008-10-27  1:18 ` Jean-Marc Spaggiari
2008-11-09 19:56 ` Rudolf Marek
2008-11-09 20:47 ` Jean Delvare
2008-11-09 20:54 ` Jean Delvare
2008-11-10  1:27 ` Jordan Crouse
2008-11-10  9:38 ` Jean Delvare
2008-11-18  8:41 ` Andreas Herrmann
2008-11-18  8:55 ` Andreas Herrmann
2008-11-18  9:06 ` Jean Delvare
2008-11-18  9:25 ` Andreas Herrmann
2008-11-18 10:10 ` Andreas Herrmann
2008-11-18 10:40 ` Jean Delvare [this message]
2008-11-18 11:18 ` Andreas Herrmann
2008-11-18 11:26 ` Andreas Herrmann
2008-11-18 12:33 ` Jean Delvare
2008-11-18 12:57 ` Jean Delvare
2008-11-18 17:46 ` Jordan Crouse
2008-11-18 18:15 ` Jean Delvare

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081118114052.17f9395b@hyperion.delvare \
    --to=khali@linux-fr.org \
    --cc=lm-sensors@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.