All of lore.kernel.org
 help / color / mirror / Atom feed
From: khali@linux-fr.org (Jean Delvare)
To: lm-sensors@vger.kernel.org
Subject: [lm-sensors] Fwd: [Bug 16755] [lm_sensors] ASSIGNED: [PATCH] Bad
Date: Mon, 11 Jul 2005 12:48:00 +0000	[thread overview]
Message-ID: <2X8THuwz.1121078561.9480250.khali@localhost> (raw)
In-Reply-To: <200507111118.03565@totor.bouissou.net>


Hi Michel,

> > * Which limits exactly don't get set by the first "sensors -s"? All?
>
> As far as I noticed, only the fans RPM thresholds are concerned.

This could be easily explained then. In your configuration file there is:

>     set fan1_min 1600  
>     set fan1_div 4  
> #   set fan2_min 1500  
>     set fan2_min 900  
>     set fan2_div 8  

You set the min limit before the clock divider, while a comment at the
top of the default sensors.conf file explicitely suggests NOT to do so:

> # A 'set fan1_div' statement must go before a 'set fan1_min' statement,
> # because the driver uses the divisor in calculating the minimum.
> # Also, one should set vrm prior to using vid in any formula.

Just try swapping the lines, and then your second "sensors -s" may no
more be necessary.

> > Please provide the output of "sensors" before the first "sensors
> > -s", after the first "sensors -s" and after the second "sensors -s".
>
> I don't have them on hand, but what I can tell from memory is that after
> the 1st "sensors -s", the fans RPM thresholds are set to 5100+ something
> RPMs, which doesn't correspond at all to what I have in sensors.conf.

Aren't there by any chance multiples of what you asked for? Or
compeletely different?

> it87: Found IT8705F chip at 0x290, revision 2
> it87 1-0290: Detected broken BIOS defaults, disabling PWM interface
>
> (What does this mean, btw ?)

That Gigabyte did not properly intialize your chip for PWM operation (fan
control). If the driver would let you use the PWM interface right now,
you'd certainly burn your system because the fans have inverted
polarity (you'd stop the fan if asking it to go full speed, and
vice-versa). So for safety we had the driver disable the interface
altogether. You can reconfigure the chip and re-enable it using the
module parameter "fix_pwm_polarity". Use at your own risk though. I'd
suggest you first complain to Gigabyte and ask them for an updated BIOS
before resorting to this.

Do you have any fan control options in your BIOS setup screens?

> > Please keep in mind that this is *expected* that reported alarms won't
> > disappear immediately after changing the limits. You will always see
> > them once after that, per chip design (you must not miss once-only
> > alarms).
>
> I understand, but what I observe prove that it's the thresholds that don't
> get set correctly as first "sensors -s" call, so it's not just an alarm
> problem...

What I meant was that your test (grep -q ALARMS) is fundamentally broken.
The second "sensors -s" is likely to run on almost all systems,
whether required or not, because it would take a second call to sensors
after the caching delay (typically 1 to 2 seconds) before all remnants
alarms wear off. But hopefully we'll find a real fix anyway, so it
doesn't really matter anymore.

So please try swapping the fan_min and fan_div lines in your
configuration file and report success or failure.

I have quite a few pending patches for that driver BTW, I was just
waiting for a bigger patch to be applied before (the one moving all
driver files around).

Thanks,
--
Jean Delvare

  parent reply	other threads:[~2005-07-11 12:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-11 11:19 [lm-sensors] Fwd: [Bug 16755] [lm_sensors] ASSIGNED: [PATCH] Bad Michel Bouissou
2005-07-11 11:49 ` Jean Delvare
2005-07-11 12:19 ` Michel Bouissou
2005-07-11 12:48 ` Jean Delvare [this message]
2005-07-11 12:57 ` Michel Bouissou
2005-07-11 13:12 ` Michel Bouissou

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=2X8THuwz.1121078561.9480250.khali@localhost \
    --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.