Bug 5168 - lm_sensors force Athlon64 (in quite&cool mode) to run CPU fan
Summary: lm_sensors force Athlon64 (in quite&cool mode) to run CPU fan
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Hardware Monitoring (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Jean Delvare
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-09-01 04:45 UTC by Roberto Colmegna
Modified: 2005-09-16 08:11 UTC (History)
0 users

See Also:
Kernel Version: Linux k900 2.6.8.1-10mdk
Subsystem:
Regression: ---
Bisected commit-id:


Attachments

Description Roberto Colmegna 2005-09-01 04:45:43 UTC
Most recent kernel where this bug did not occur: NA

Distribution: Mandrake 10.1

Hardware Environment: Athlon 64 3000+ with Quite&cool enabled from BIOS

Software Environment: NA

Problem Description:
Krn 2.6.8 correctly handle quite&cool-mode on AMD Athlon64. If CPU have
a small/no load the CPU-fan is disabled. 
But when the lm_sensors modules are loaded the CPU-fan immediatly start
to run (the direct correlation load modules->fan run is reproducible
everytime). If modules aren't load the CPU-fan run only in case of
high CPU load.

Steps to reproduce:
- AMD Athlon 64 (MB ASUS A8V with VIA K8T800Pro + VT8237)
- linux krn. 2.6.8
- lm_sensors
Comment 1 Jean Delvare 2005-09-01 05:18:27 UTC
Which "lm_sensors drivers" are you using exactly? What matters here is the chip
driver, most probably one of asb100, w83781d, w83627hf or it87.

Which hardware monitoring chip is on this board exactly?

Is the CPU fan spin-up caused by merely loading the chip driver, or by running
"sensors -s" afterwards? In the latter case, please provide the relevant part of
/etc/sensors.conf.
Comment 2 Roberto Colmegna 2005-09-01 05:56:09 UTC
lm_sensors drivers: w83627hf 

hardware monitor model/type: UNKNOW
(http://usa.asus.com/products/mb/socket939/a8v-d/overview.htm)

"sensors" params: my /etc/rc.d/init.d/lm_sensors use "sensors -s"

I modified init.d script and I note that without "sensors -s" (only
with modules loaded) the problem IS present. So, I argue that the
problem is in modules  :)

I tried to unload modules (via modprobe -r) but the CPU-fun
doesn't stop it ... :(

I also loaded modules one-by-one, and I noticed that ONLY when I 
execute "modprobe w83627hf" the CPU-fun begin to run.

THX for your help

----------- /etc/sysconfig/lm_sensors ---------------
MODULE_0=i2c-viapro
MODULE_1=i2c-isa
MODULE_2=lm75
MODULE_3=eeprom
MODULE_4=smbus-arp
MODULE_5=w83627hf
----------- /etc/sysconfig/lm_sensors  END ---------------

------------- /etc/sensors.conf ------------------
[...snip...]
chip "w83782d-*" "w83627hf-*"

# Same as above for w83781d except that in5 and in6 are computed differently.
# Rather than an internal inverting op amp, the 82d/83s use standard positive
# inputs and the negative voltages are level shifted by a 3.6V reference.
# The math is convoluted, so we hope that your motherboard
# uses the recommended resistor values.

    label in0 "VCore 1"
    label in1 "VCore 2"
    label in2 "+3.3V"
    label in3 "+5V"
    label in4 "+12V"
    label in5 "-12V"
    label in6 "-5V"
    label in7 "V5SB"
    label in8 "VBat"

# Abit BP6 motherboard has a few differences. VCore1 and VCore2 are the core
# voltages of the two processors. Vtt is memory bus termination resistors
# voltage.
#    label in1 "Vtt"
#    label in8 "VCore2"

    compute in3 ((6.8/10)+1)*@ ,  @/((6.8/10)+1)
    compute in4 ((28/10)+1)*@  ,  @/((28/10)+1)
    compute in5 (5.14 * @) - 14.91  ,  (@ + 14.91) / 5.14
    compute in6 (3.14 * @) -  7.71  ,  (@ +  7.71) / 3.14
    compute in7 ((6.8/10)+1)*@ ,  @/((6.8/10)+1)
# adjust this if your vid is wrong; see doc/vid
#   set vrm 9.0

# set limits to  5% for the critical voltages
# set limits to 10% for the non-critical voltages
# set limits to 20% for the battery voltage

    set in0_min vid*0.95
    set in0_max vid*1.05
    set in1_min vid*0.95
    set in1_max vid*1.05
    set in2_min 3.3 * 0.95
    set in2_max 3.3 * 1.05
    set in3_min 5.0 * 0.95
    set in3_max 5.0 * 1.05
    set in4_min 12 * 0.90
    set in4_max 12 * 1.10
    set in5_max -12 * 0.90
    set in5_min -12 * 1.10
    set in6_max -5 * 0.95
    set in6_min -5 * 1.05
    set in7_min 5 * 0.95
    set in7_max 5 * 1.05
    set in8_min 3.0 * 0.80
    set in8_max 3.0 * 1.20

# set up sensor types (thermistor is default)
# 1 = PII/Celeron Diode; 2 = 3904 transistor;
# 3435 = thermistor with Beta = 3435
# If temperature changes very little, try 1 or 2.
#   set sensor1 1
#   set sensor2 2
#   set sensor3 3435

# examples for temperature limits
#    set temp1_over 40
#    set temp1_hyst 37
#    set temp2_over 52
#    set temp2_hyst 47
#    set temp3_over 52
#    set temp3_hyst 47

[...snip...]
------------- /etc/sensors.conf END ------------------
Comment 3 Jean Delvare 2005-09-01 06:26:23 UTC
Please provide the output of "sensors".

Try without loading lm75 driver and see if it makes a difference.

Try loading w83627hf with "init=0" and see it it helps.
Comment 4 Roberto Colmegna 2005-09-01 07:58:46 UTC
loading WITHOUT lm75 driver: NOT USEFUL

loading w83627hf with "init=0": USEFUL!!!! IT WORKS!!! A GREAT SHOT!!!
... but /etc/rc.d/init.d/lm_sensors doesn't support the syntax 
"MODULE_5=w83627hf init=0" in /etc/sysconfig/lm_sensors. 

THX A LOT!!! :)
Comment 5 Jean Delvare 2005-09-01 08:04:06 UTC
Do not edit the /etc/sysconfig/lm_sensors file. Instead, add the following to
/etc/modprobe.conf (or where it fits if that file is generated on your
distribution):

options w83627hf init=0

Comment 6 Jean Delvare 2005-09-16 08:11:15 UTC
The w83627hf driver in 2.6.14-rc1 now defaults to no reset on load. Reset can be
forced with reset=1. It will probably go away entirely after 2.6.14.

Note You need to log in before you can comment on or make changes to this bug.