[lm-sensors] Fwd: [Bug 16755] [lm_sensors] ASSIGNED: [PATCH] Bad

[lm-sensors] Fwd: [Bug 16755] [lm_sensors] ASSIGNED: [PATCH] Bad

[Michel Bouissou]

So they asked me to bug you ;-))

(BTW the sensors@stimpy.netroedge.com email address mentioned on the 
http://www2.lm-sensors.nu/~lm78/support.html web page bounces with "User 
unknown"...)


----------  Message transmis  ----------

Subject: [Bug 16755] [lm_sensors] ASSIGNED: [PATCH] Bad IT87 sensor 
initialization
Date: Samedi 09 Juillet 2005 10:56
From: [mdk] <bugzilla@qa.mandriva.com>
To: michel@bouissou.net

User ID: 5399, 105 bugs reported (73 fixed, 4 duplicate, 10 invalid), 333
 comments.

http://qa.mandriva.com/show_bug.cgi?id\x16755


mdk@agat.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1




------- Additional Comments From mdk@agat.net  2005-07-09 10:56 -------
ok, nice catch.
I'll use this patch if no new release of lm_sensors fixes this bug.

Bug the lm_sensors mens with your issue, it isn't normal to use "sensors -s"
twice to initialize some components.

--
Configure bugmail: http://qa.mandriva.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.


------- Reminder: -------
assigned_to: mdk@agat.net
status: ASSIGNED
distribution: 10.2-community
creation_date:
description:
Hi there,

On a Gigabyte GA-7VAXP motherboard (Athlon XP CPU, Via KT400 chipset),
 there's an IT87 sensor, that is managed by the it87 module.

It appears than on this MB, starting the "lm_sensors" service doesn't allow
proper initialization of the IT87 : Alarm threshold values don't get set
properly unless "sensors -s" is called a 2nd time, and then, it's OK.

I propose the following simple patch to the lm_sensors script, that just
 calls "sensors -s" a 2nd time if "sensors" reports an alarm after "sensors
 -s" has been called the 1st time.

It fixes the issue plain good here, and shouldn't interfere with systems that
don't have such problems.

Here's the proposed patch:

--- lm_sensors.Original.mdk102  2005-07-08 12:09:34.000000000 +0200
+++ lm_sensors  2005-07-08 12:13:14.000000000 +0200
@@ -57,6 +59,7 @@
        echo
        # Set Alarm
        sensors -s && sleep 2
+       sensors | grep -q "ALARM" && { sensors -s && sleep 2; }
         # Start daemons.
         gprintf "Starting sensord: "
         daemon sensord -i 1m -l 30m


Besides, I don't know if this may help, but here are the proper sensors.conf
settings for the sensors modules that works with this MB (voltage factors
checked with a multimeter):

# MiB
# Modifie par Michel Bouissou le 29/09/2004
# pour CM Gigabyte GA-7VAXP
# Chipset VIA KT400 + ITE IT8705F

chip "it87-*"

    label "in0" "CPU core"
    label "in1" "DDRAM"
    label "in2" "3v3 I/O"
    label "in3" "+5V"
    label "in4" "+12V"
    label "in5" "-12V"
#    ignore "in5"
    label "in6" "-5V"
#    ignore "in6"
    label "in7" "Stdby"
    label "in8" "Vbat"
    ignore "in8"
    ignore "vid"

    label fan1  "CPU Fan"
    label fan2  "BOX Fan"
    label fan3  "PWR Fan"
    ignore fan3

    label temp1 "IT87 T??"
    label temp2 "UNUSED"
    ignore temp2
    label temp3 "UNUSED"
    ignore temp3

#   Tol??rances larges : -10% / +8%
#   Tol??rances serr??es: +/- 5% (Sp??cifications ATX)
# CPU Core
    set in0_min 1.75 * 0.95
    set in0_max 1.75 * 1.05
# DDRAM
    set in1_min 1.25 * 0.94
    set in1_max 1.25 * 1.06
# +3.3V
# Tol??rances Antec pour +3.3V: +/- 3%
    set in2_min 3.3 * 0.95
    set in2_max 3.3 * 1.05
# +5V
# Tol??rances Antec pour +5V: +/- 3%
    set in3_min 5 * 0.95
    set in3_max 5 * 1.05
# +12V
# Tol??rances Antec pour +12V: +/- 3%
    set in4_min 12 * 0.95
    set in4_max 12 * 1.05
# -12V
# Tol??rances larges pour -12V (Oscille car non charg??)
    set in5_min -12 * 0.60
    set in5_max -12 * 1.40
# -5V
# Tol??rances tr??s larges pour -5V (Oscille car non charg??)
    set in6_min -5 * 0.50
    set in6_max -5 * 2.00
# +5V StdBy
    set in7_min 5 * 0.95
    set in7_max 5 * 1.05

#    set temp1_hyst 50
    set temp1_over 55
    set temp1_low 15

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

#   +5V
#   compute "in3" ((6.8/10)+1)*@ , @/((6.8/10)+1)
#   Coeff ci-dessous r??gl?? au multim??tre
    compute "in3" ((7.2/10)+1)*@ , @/((7.2/10)+1)
#   +12V
    compute "in4" ((30/10)+1)*@ , @/((30/10)+1)
    compute "in5" -(56/10)*@ , -@/(56/10)
    compute "in6" -(36/10)*@ , -@/(36/10)
#   Coeff ci-dessous report?? d'apr??s +5V r??gl??
#   compute "in7" ((6.8/10)+1)*@ , @/((6.8/10)+1)
    compute "in7" ((7.2/10)+1)*@ , @/((7.2/10)+1)


chip "lm90-*" "adm1032-*"

   label temp1 "LM90 T??"
   label temp2 "Athlon T??"
   label tcrit1 "LM90 Crit"
   label tcrit2 "CPU Crit"

# change high and low limits to fit your needs
   set temp1_low  15
   set temp1_high 60
   set temp2_low  15
   set temp2_high 70

# change critical limits to fit your needs
# should be higher than the corresponding high limit above
   set tcrit1 70
   set tcrit2 80


-------------------------------------------------------

-- 
Michel Bouissou <michel@bouissou.net> OpenPGP ID 0xDDE8AC6E

[lm-sensors] Fwd: [Bug 16755] [lm_sensors] ASSIGNED: [PATCH] Bad

[Jean Delvare]

Salut Michel,

On 2005-07-11, Michel Bouissou wrote:
> So they asked me to bug you ;-))

And quite rightly so, this is indeed not acceptable that sensors -s has
to be ran twice.

Unfortunately your report isn't as complete as it would need to be for
us to help you. We would need to know:

* Which version of the Linux kernel you are using.

* If this kernel has patches applied which could affect the i2c subsystem
or the it87 driver, we need to know which they are and what they do.

* Which version of "sensors" and "libsensors" you are using.

* If lm_sensors has patches applied, we need a list.

* What is your it87-compatible chip? IT8705? IT87012F? Which revision, if
you happen to know? Is it accessed through the SMBus or as an ISA device?

* The complete sensors initialization script used.

* Which limits exactly don't get set by the first "sensors -s"? All?
Please provide the output of "sensors" before the first "sensors
-s", after the first "sensors -s" and after the second "sensors -s".

* Anything in the logs?

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).

> (BTW the sensors@stimpy.netroedge.com email address mentioned on the
> http://www2.lm-sensors.nu/~lm78/support.html web page bounces with "User
> unknown"...)

Correct, I just asked our administrator to fix it. Thanks for reporting.

--
Jean Delvare

[lm-sensors] Fwd: [Bug 16755] [lm_sensors] ASSIGNED: [PATCH] Bad

[Michel Bouissou]

Le Lundi 11 Juillet 2005 11:41, Jean Delvare a ?crit :
> Salut Michel,

Salut :-)

> Unfortunately your report isn't as complete as it would need to be for
> us to help you. We would need to know:

So I'll try my best ;-)

> * Which version of the Linux kernel you are using.

That's a 2.6.12-3mib3v ;-) which means a custom compilation of the Mandrake's 
cooker 2.6.12-3

Let me add immediately that I have always had the same lm_sensors "double 
initialization needed problem" since I have this board (Gigabyte GA7-VAXP), 
and thru each and every version of 2.4.x or 2.6.x kernels, and every version 
of lm_sensors I ran on it, for a long time... I had just been too lazy to 
report the problem before, but this problem is not related to this precise 
kernel...

> * If this kernel has patches applied which could affect the i2c subsystem
> or the it87 driver, we need to know which they are and what they do.

Well, being a Mandrake kernel, it includes a number of patches from Mdk, which 
complete list I'm not aware of...

> * Which version of "sensors" and "libsensors" you are using.

These are Mandrake RPMs, I suppose the version is accurate...:
[root@totor etc]# rpm -qa | grep -i sensors
liblm_sensors3-devel-2.9.0-4mdk
lm_sensors-2.9.0-4mdk
liblm_sensors3-2.9.0-4mdk

> * If lm_sensors has patches applied, we need a list.

Uh... I'll try to get one from the source RPMs if you think it's absolutely 
necessary ;-))

> * What is your it87-compatible chip? IT8705? IT87012F? Which revision, if
> you happen to know? Is it accessed through the SMBus or as an ISA device?

ITE - IT8705F is written on the chip itself. lm_sensors accesses it thru the 
ISA bus.

> * The complete sensors initialization script used.

Please see attached. It's Mandrake's one... Just with my patch to call 
"sensors -s" a 2nd time if there are alarms.

> * 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.

> 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.

After the 2nd "sensors -s", they are set properly.

Here's the output of "sensors" with everything set properly here:

[root@totor etc]# sensors
lm90-i2c-0-4c
Adapter: SMBus Via Pro adapter at 5000
LM90 T?:     +48?C  (low  =   +15?C, high =   +60?C)
Athlon T?: +50.8?C  (low  = +15.0?C, high = +70.0?C)
LM90 Crit:   +70?C  (hyst =   +60?C)
CPU Crit:    +80?C  (hyst =   +70?C)

it87-isa-0290
Adapter: ISA adapter
CPU core:  +1.74 V  (min =  +1.66 V, max =  +1.84 V)
DDRAM:     +1.22 V  (min =  +1.17 V, max =  +1.33 V)
3v3 I/O:   +3.23 V  (min =  +3.14 V, max =  +3.47 V)
+5V:       +5.04 V  (min =  +4.76 V, max =  +5.26 V)
+12V:     +11.97 V  (min = +11.39 V, max = +12.61 V)
-12V:     -11.11 V  (min =  -7.17 V, max = -16.76 V)
-5V:       -6.28 V  (min =  -2.48 V, max = -10.02 V)
Stdby:     +5.09 V  (min =  +4.76 V, max =  +5.26 V)
CPU Fan:  2057 RPM  (min = 1599 RPM, div = 4)
BOX Fan:  1318 RPM  (min =  897 RPM, div = 8)


> * Anything in the logs?

Nothing special is visible when starting lm_sensors, but my kernel logs the 
following during its boot sequence:

it87: Found IT8705F chip at 0x290, revision 2
it87 1-0290: Detected broken BIOS defaults, disabling PWM interface

(What does this mean, btw ?)

> 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...

Cheers.

-- 
Michel Bouissou <michel@bouissou.net> OpenPGP ID 0xDDE8AC6E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lm_sensors.gz
Type: application/x-gzip
Size: 1168 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20050711/5bfcebc3/lm_sensors.gz

[lm-sensors] Fwd: [Bug 16755] [lm_sensors] ASSIGNED: [PATCH] Bad

[Jean Delvare]

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

[lm-sensors] Fwd: [Bug 16755] [lm_sensors] ASSIGNED: [PATCH] Bad

[Michel Bouissou]

Le Lundi 11 Juillet 2005 12:42, Jean Delvare a ?crit :
>
> 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:

OOOops !!!

I usually reads the docs thoroughly (yes I do ;-) but I had missed this one... 
I'm not familar with the order of parameters being of any importance in 
config files...

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

I'll check this.

> > 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?

No. AFAIK, my board is capable of reporting the fans speeds, but doesn't have 
active control over them. That's probably why these BIOS defaults are 
"broken".

My CPU fan is controlled via a manual potentiometer, and my box fans are under 
control of my power supply (Antec) that reports their speed to the MB thru a 
specific cable.

Thanks for the help !

-- 
Michel Bouissou <michel@bouissou.net> OpenPGP ID 0xDDE8AC6E

[lm-sensors] Fwd: [Bug 16755] [lm_sensors] ASSIGNED: [PATCH] Bad

[Michel Bouissou]

Le Lundi 11 Juillet 2005 12:42, Jean Delvare a ?crit :
> Just try swapping the lines, and then your second "sensors -s" may no
> more be necessary.

You were right, shame on me :-(

This parameter ordering issue got me :-/

-- 
Michel Bouissou <michel@bouissou.net> OpenPGP ID 0xDDE8AC6E