All of lore.kernel.org
 help / color / mirror / Atom feed
From: gcoady@gmail.com (Grant Coady)
To: lm-sensors@vger.kernel.org
Subject: [lm-sensors] [Ticket #2078] sensor values are sometimes wrong
Date: Fri, 21 Oct 2005 11:39:07 +0000	[thread overview]
Message-ID: <4358B6C8.40401@gmail.com> (raw)
In-Reply-To: <20051021083606.GB19748@westend.com>

Christian Hammers wrote:
> Hello
> 
> It seems to be related to the above mentioned bug number but the FAQ was
> a bit unclear how to include the ticket number in the subject :)
> 
> My problem is that sensors sometimes reports confusing values i.e.
> - it prints ALERT although the corresponding values are fine, the ALERT
>   then vanished in the next read

Yup, that is what the sensor chip reports.  It is up to _you_ properly
process the signals to suit your requirements.  ALERT is typically
cleared by the act of reading a value.
> - sensor values give suddenly 0 or arbitrary values

The sensor chips operate in an extremely noisy electrical environment,
stuff happens, your application software may denounce this.

> - configured limits are 0 for one or two reads and then go back to the
>   defined value

Again nature of the beast, your expectations do not match reality :o)

> - chassis intrusion is set just for a couple of seconds

So denounce it?
> 
> This makes it absolutely unusable for monitoring in production use.

No, you expect a kernel driver to do the work of a custom user-space
solution, IOW you want the kernel to enforce policy.  The kernel +
drivers do not enforce policy, they control access to resources.

> I had have this before on several other mainboards, too. It can be
> circumvented by reading the sensors output trice and only alert if you
> get an alert in all three readings but this should not be the task of
> the user :) On this mainboard here it is worse than ever though.

Yes, because you need to better understand the issues, when everything
looks wrong, it is time to check the viewer.  No?

> Data for this mainboard although the problem is more general and
> experienced on several other models and brands, too:

I don't do free consulting.

Grant.

  reply	other threads:[~2005-10-21 11:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-21 10:37 [lm-sensors] [Ticket #2078] sensor values are sometimes wrong Christian Hammers
2005-10-21 11:39 ` Grant Coady [this message]
2005-10-21 12:07 ` Christian Hammers
2005-10-23 22:40 ` Rudolf Marek
2005-10-24 10:11 ` Christian Hammers
2005-10-25 22:49 ` Rudolf Marek

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=4358B6C8.40401@gmail.com \
    --to=gcoady@gmail.com \
    --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.