[lm-sensors] [Bug?] W83697: Broken readings for fan speed 10% of

[lm-sensors] [Bug?] W83697: Broken readings for fan speed 10% of

[Bruno Prémont]

On a Commell LE-365 I get readings for fan speed that are broken about
10% of the time.
The board has a Winbond W83697 chip (I can't check the exact chip name
on the board as it's hidden by a heatsink, the photo from Commell, as
as well as the manual indicate a HG, the kenrel reports:
  [    3.572831] w83627hf: Found W83697HF chip at 0x290
  [    3.572831] WDT driver for the Winbond(TM) W83627HF/THF/HG Super I/O chip initialising.
  [    3.572831] w83627hf/thf/hg WDT: Watchdog already running. Resetting timeout to 60 sec
  [    3.572831] w83627hf/thf/hg WDT: initialized. timeout` sec (nowayout=0)
)

Below a sample (reformatted) output of
  while sleep 1; do
    date;
    cat /sys/class/hwmon/hwmon0/device/fan1_input;
  done
:
Sat May 31 21:11:23 CEST 2008    2070
Sat May 31 21:11:24 CEST 2008    2070
Sat May 31 21:11:25 CEST 2008    2070
Sat May 31 21:11:26 CEST 2008    2070
Sat May 31 21:11:27 CEST 2008    2070
Sat May 31 21:11:28 CEST 2008    2070
Sat May 31 21:11:29 CEST 2008    2057
Sat May 31 21:11:30 CEST 2008    2057
Sat May 31 21:11:31 CEST 2008    2070
Sat May 31 21:11:32 CEST 2008    2070
Sat May 31 21:11:33 CEST 2008      -1
Sat May 31 21:11:34 CEST 2008      -1
Sat May 31 21:11:35 CEST 2008      -1
Sat May 31 21:11:36 CEST 2008      -1
Sat May 31 21:11:37 CEST 2008    2057
Sat May 31 21:11:38 CEST 2008    2057
Sat May 31 21:11:39 CEST 2008    2057
Sat May 31 21:11:40 CEST 2008    2057
Sat May 31 21:11:41 CEST 2008    2070
Sat May 31 21:11:42 CEST 2008    2070
Sat May 31 21:11:43 CEST 2008    2070
Sat May 31 21:11:44 CEST 2008    2070
Sat May 31 21:11:45 CEST 2008    2057
Sat May 31 21:11:46 CEST 2008    2057
Sat May 31 21:11:47 CEST 2008      -1
Sat May 31 21:11:48 CEST 2008      -1
Sat May 31 21:11:49 CEST 2008    2070
Sat May 31 21:11:50 CEST 2008    2070
Sat May 31 21:11:51 CEST 2008    2057
Sat May 31 21:11:52 CEST 2008    2057
Sat May 31 21:11:53 CEST 2008    2057
Sat May 31 21:11:54 CEST 2008    2057
Sat May 31 21:11:55 CEST 2008    2057
Sat May 31 21:11:56 CEST 2008    2057
Sat May 31 21:11:58 CEST 2008    2057
Sat May 31 21:11:59 CEST 2008    2057
Sat May 31 21:12:00 CEST 2008    2070
Sat May 31 21:12:01 CEST 2008    2070
Sat May 31 21:12:02 CEST 2008    2057
Sat May 31 21:12:03 CEST 2008    2057
Sat May 31 21:12:04 CEST 2008    2083
Sat May 31 21:12:05 CEST 2008    2083
Sat May 31 21:12:06 CEST 2008    2057
Sat May 31 21:12:07 CEST 2008    2057
Sat May 31 21:12:08 CEST 2008    2070
Sat May 31 21:12:09 CEST 2008    2070
Sat May 31 21:12:10 CEST 2008    2070
Sat May 31 21:12:11 CEST 2008    2070
Sat May 31 21:12:12 CEST 2008  337500
Sat May 31 21:12:13 CEST 2008  337500
Sat May 31 21:12:14 CEST 2008  337500
Sat May 31 21:12:15 CEST 2008  337500
Sat May 31 21:12:16 CEST 2008  337500
Sat May 31 21:12:17 CEST 2008  337500
Sat May 31 21:12:18 CEST 2008    2070
Sat May 31 21:12:19 CEST 2008    2070
Sat May 31 21:12:20 CEST 2008    2070
Sat May 31 21:12:21 CEST 2008    2070
Sat May 31 21:12:22 CEST 2008    2070
Sat May 31 21:12:23 CEST 2008    2070
Sat May 31 21:12:24 CEST 2008    2070
Sat May 31 21:12:25 CEST 2008    2070
Sat May 31 21:12:26 CEST 2008    2057
Sat May 31 21:12:27 CEST 2008    2057
Sat May 31 21:12:28 CEST 2008    2070
Sat May 31 21:12:29 CEST 2008    2070
Sat May 31 21:12:30 CEST 2008    2070
Sat May 31 21:12:31 CEST 2008    2070
Sat May 31 21:12:32 CEST 2008      -1

The 337k RPM and -1 RPM do not make any sense.
I can't tell if this is a regression as I just started monitoring
a few sensor values (with older kernels I just did a few manual
checks but never noticed broken fan speeds)

In case there is more data I can provide, please ask.
As the board is not in production use I can easily try out patches.

Regards,
Bruno


I've configured the sensor chip with (lm_sensors-3.0.1)
  chip "w83697hf-*"
    label in0 "VCore"
    label in2 "+3.3V"
    label in3 "+5V"
    label in4 "+12V"
    label in5 "-12V"
    label in6 "-5V"
    label in7 "V5SB"
    label in8 "VBat"

    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)

    set in0_min 0.844 * 0.95
    set in0_max 0.844 * 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 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 fan1_div 4
    set fan1_min 1000
    set fan2_min 0

Two sample outputs of sensors:
  w83697hf-isa-0290
  Adapter: ISA adapter
  VCore:       +0.83 V  (min =  +0.80 V, max =  +0.88 V)   
  +3.3V:       +3.28 V  (min =  +3.14 V, max =  +3.47 V)   
  +5V:         +5.00 V  (min =  +4.76 V, max =  +5.24 V)   
  +12V:        +7.90 V  (min = +10.82 V, max = +13.19 V)   ALARM
  -12V:        +1.95 V  (min =  -1.50 V, max = -11.13 V)   ALARM
  -5V:         +2.64 V  (min =  -4.65 V, max =  -5.95 V)   ALARM
  V5SB:        +5.48 V  (min =  +4.76 V, max =  +5.24 V)   ALARM
  VBat:        +3.17 V  (min =  +2.40 V, max =  +3.60 V)   
  fan1:       337500 RPM  (min = 1328 RPM, div = 4)
  fan2:          0 RPM  (min =    0 RPM, div = 16)
  temp1:       +48.0 C  (high = +56.0 C, hyst = -77.0 C)  sensor   thermistor temp2:       +52.0 C  (high = +100.0 C, hyst = +95.0 C)
  sensor = thermistor beep_enable:enabled

  w83697hf-isa-0290
  Adapter: ISA adapter
  VCore:       +0.82 V  (min =  +0.80 V, max =  +0.88 V)   
  +3.3V:       +3.28 V  (min =  +3.14 V, max =  +3.47 V)   
  +5V:         +5.00 V  (min =  +4.76 V, max =  +5.24 V)   
  +12V:        +7.84 V  (min = +10.82 V, max = +13.19 V)   ALARM
  -12V:        +1.95 V  (min =  -1.50 V, max = -11.13 V)   ALARM
  -5V:         +2.64 V  (min =  -4.65 V, max =  -5.95 V)   ALARM
  V5SB:        +5.48 V  (min =  +4.76 V, max =  +5.24 V)   ALARM
  VBat:        +3.17 V  (min =  +2.40 V, max =  +3.60 V)   
  fan1:       2083 RPM  (min = 1328 RPM, div = 4)
  fan2:          0 RPM  (min =    0 RPM, div = 16)
  temp1:       +47.0 C  (high = +56.0 C, hyst = -77.0 C)  sensor   thermistor temp2:       +52.0 C  (high = +100.0 C, hyst = +95.0 C)
  sensor = thermistor beep_enable:enabled

Note: I tried divisors 4, 16, 32, all with same final behavior.

Kernel config snipplet:
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
CONFIG_SENSORS_W83627HF=y
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_SENSORS_APPLESMC is not set

CONFIG_W83627HF_WDT=y
# CONFIG_W83697HF_WDT is not set
# CONFIG_W83877F_WDT is not set
# CONFIG_W83977F_WDT is not set

Kernel messages:
[    0.000000] Linux version 2.6.25.3 (bruno@venus) (gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2)) #1 Mon May 12 19:57:16 CEST 2008
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
[    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 000000003bee0000 (usable)
[    0.000000]  BIOS-e820: 000000003bee0000 - 000000003bee3000 (ACPI NVS)
[    0.000000]  BIOS-e820: 000000003bee3000 - 000000003bef0000 (ACPI data)
[    0.000000]  BIOS-e820: 000000003bef0000 - 000000003bf00000 (reserved)
[    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
[    0.000000] 62MB HIGHMEM available.
[    0.000000] 896MB LOWMEM available.
...
[    3.401878] i2c /dev entries driver
[    3.572831] w83627hf: Found W83697HF chip at 0x290
[    3.572831] WDT driver for the Winbond(TM) W83627HF/THF/HG Super I/O chip initialising.
[    3.572831] w83627hf/thf/hg WDT: Watchdog already running. Resetting timeout to 60 sec
[    3.572831] w83627hf/thf/hg WDT: initialized. timeout` sec (nowayout=0)


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

Re: [lm-sensors] [Bug?] W83697: Broken readings for fan speed 10%

[Grant Coady]

On Sat, 31 May 2008 22:03:39 +0200, Bruno Prémont <bonbons@linux-vserver.org> wrote:

>On a Commell LE-365 I get readings for fan speed that are broken about
>10% of the time.
>The board has a Winbond W83697 chip (I can't check the exact chip name
>on the board as it's hidden by a heatsink, the photo from Commell, as
>as well as the manual indicate a HG, the kenrel reports:
>  [    3.572831] w83627hf: Found W83697HF chip at 0x290
>  [    3.572831] WDT driver for the Winbond(TM) W83627HF/THF/HG Super I/O chip initialising.
>  [    3.572831] w83627hf/thf/hg WDT: Watchdog already running. Resetting timeout to 60 sec
>  [    3.572831] w83627hf/thf/hg WDT: initialized. timeout` sec (nowayout=0)
>)
>
>Below a sample (reformatted) output of
>  while sleep 1; do
>    date;
>    cat /sys/class/hwmon/hwmon0/device/fan1_input;
>  done

Try slowing down your polling, change to sleep 5.  See if the problem goes 
away.

Grant.

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

Re: [lm-sensors] [Bug?] W83697: Broken readings for fan speed 10%

[Bruno Prémont]

On Sun, 01 June 2008 Grant Coady <grant_lkml@dodo.com.au> wrote:
> On Sat, 31 May 2008 22:03:39 +0200, Bruno Prémont
> <bonbons@linux-vserver.org> wrote:
> 
> >On a Commell LE-365 I get readings for fan speed that are broken
> >about 10% of the time.
> >The board has a Winbond W83697 chip (I can't check the exact chip
> >name on the board as it's hidden by a heatsink, the photo from
> >Commell, as as well as the manual indicate a HG, the kenrel reports:
> >  [    3.572831] w83627hf: Found W83697HF chip at 0x290
> >  [    3.572831] WDT driver for the Winbond(TM) W83627HF/THF/HG
> > Super I/O chip initialising. [    3.572831] w83627hf/thf/hg WDT:
> > Watchdog already running. Resetting timeout to 60 sec
> > [    3.572831] w83627hf/thf/hg WDT: initialized. timeout` sec
> > (nowayout=0)
> >)
> >
> >Below a sample (reformatted) output of
> >  while sleep 1; do
> >    date;
> >    cat /sys/class/hwmon/hwmon0/device/fan1_input;
> >  done
> 
> Try slowing down your polling, change to sleep 5.  See if the problem
> goes away.
> 
> Grant.
> 
Unfortunately polling less often does not help.
The monitoring software which made me see this issue is polling once
every 10 seconds, I don't see the -1s there, but the too large values
do show up.

Bruno

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

Re: [lm-sensors] [Bug?] W83697: Broken readings for fan speed 10%

[Jean Delvare]

Hi Bruno,

On Sat, 31 May 2008 22:03:39 +0200, Bruno Prémont wrote:
> On a Commell LE-365 I get readings for fan speed that are broken about
> 10% of the time.
> The board has a Winbond W83697 chip (I can't check the exact chip name
> on the board as it's hidden by a heatsink, the photo from Commell, as
> as well as the manual indicate a HG, the kenrel reports:
>   [    3.572831] w83627hf: Found W83697HF chip at 0x290
>   [    3.572831] WDT driver for the Winbond(TM) W83627HF/THF/HG Super I/O chip initialising.
>   [    3.572831] w83627hf/thf/hg WDT: Watchdog already running. Resetting timeout to 60 sec
>   [    3.572831] w83627hf/thf/hg WDT: initialized. timeout` sec (nowayout=0)
> )
> 
> Below a sample (reformatted) output of
>   while sleep 1; do
>     date;
>     cat /sys/class/hwmon/hwmon0/device/fan1_input;
>   done
> :
> Sat May 31 21:11:23 CEST 2008    2070
> Sat May 31 21:11:24 CEST 2008    2070
> Sat May 31 21:11:25 CEST 2008    2070
> Sat May 31 21:11:26 CEST 2008    2070
> Sat May 31 21:11:27 CEST 2008    2070
> Sat May 31 21:11:28 CEST 2008    2070
> Sat May 31 21:11:29 CEST 2008    2057
> Sat May 31 21:11:30 CEST 2008    2057
> Sat May 31 21:11:31 CEST 2008    2070
> Sat May 31 21:11:32 CEST 2008    2070
> Sat May 31 21:11:33 CEST 2008      -1
> Sat May 31 21:11:34 CEST 2008      -1
> Sat May 31 21:11:35 CEST 2008      -1
> Sat May 31 21:11:36 CEST 2008      -1
> Sat May 31 21:11:37 CEST 2008    2057
> Sat May 31 21:11:38 CEST 2008    2057
> Sat May 31 21:11:39 CEST 2008    2057
> Sat May 31 21:11:40 CEST 2008    2057
> Sat May 31 21:11:41 CEST 2008    2070
> Sat May 31 21:11:42 CEST 2008    2070
> Sat May 31 21:11:43 CEST 2008    2070
> Sat May 31 21:11:44 CEST 2008    2070
> Sat May 31 21:11:45 CEST 2008    2057
> Sat May 31 21:11:46 CEST 2008    2057
> Sat May 31 21:11:47 CEST 2008      -1
> Sat May 31 21:11:48 CEST 2008      -1
> Sat May 31 21:11:49 CEST 2008    2070
> Sat May 31 21:11:50 CEST 2008    2070
> Sat May 31 21:11:51 CEST 2008    2057
> Sat May 31 21:11:52 CEST 2008    2057
> Sat May 31 21:11:53 CEST 2008    2057
> Sat May 31 21:11:54 CEST 2008    2057
> Sat May 31 21:11:55 CEST 2008    2057
> Sat May 31 21:11:56 CEST 2008    2057
> Sat May 31 21:11:58 CEST 2008    2057
> Sat May 31 21:11:59 CEST 2008    2057
> Sat May 31 21:12:00 CEST 2008    2070
> Sat May 31 21:12:01 CEST 2008    2070
> Sat May 31 21:12:02 CEST 2008    2057
> Sat May 31 21:12:03 CEST 2008    2057
> Sat May 31 21:12:04 CEST 2008    2083
> Sat May 31 21:12:05 CEST 2008    2083
> Sat May 31 21:12:06 CEST 2008    2057
> Sat May 31 21:12:07 CEST 2008    2057
> Sat May 31 21:12:08 CEST 2008    2070
> Sat May 31 21:12:09 CEST 2008    2070
> Sat May 31 21:12:10 CEST 2008    2070
> Sat May 31 21:12:11 CEST 2008    2070
> Sat May 31 21:12:12 CEST 2008  337500
> Sat May 31 21:12:13 CEST 2008  337500
> Sat May 31 21:12:14 CEST 2008  337500
> Sat May 31 21:12:15 CEST 2008  337500
> Sat May 31 21:12:16 CEST 2008  337500
> Sat May 31 21:12:17 CEST 2008  337500
> Sat May 31 21:12:18 CEST 2008    2070
> Sat May 31 21:12:19 CEST 2008    2070
> Sat May 31 21:12:20 CEST 2008    2070
> Sat May 31 21:12:21 CEST 2008    2070
> Sat May 31 21:12:22 CEST 2008    2070
> Sat May 31 21:12:23 CEST 2008    2070
> Sat May 31 21:12:24 CEST 2008    2070
> Sat May 31 21:12:25 CEST 2008    2070
> Sat May 31 21:12:26 CEST 2008    2057
> Sat May 31 21:12:27 CEST 2008    2057
> Sat May 31 21:12:28 CEST 2008    2070
> Sat May 31 21:12:29 CEST 2008    2070
> Sat May 31 21:12:30 CEST 2008    2070
> Sat May 31 21:12:31 CEST 2008    2070
> Sat May 31 21:12:32 CEST 2008      -1
> 
> The 337k RPM and -1 RPM do not make any sense.
> I can't tell if this is a regression as I just started monitoring
> a few sensor values (with older kernels I just did a few manual
> checks but never noticed broken fan speeds)

I do not think this is a regression, most likely a hardware issue.

Is the fan's speed controlled in any way, either by the W83697HG chip,
or maybe it is a self-regulated fan? Just check if the fan's speed
increases with the temperature (i.e. with CPU load).

If this is the case, then please read this recent discussion the
lm-sensors list:
  http://marc.info/?l=lm-sensors&m\x121196069612940&w=2
I suspect that your problem is similar.

If the fan is not controlled and is running at full speed, then all I
can think of is defective hardware (either the fan or the monitoring
chip.)

> In case there is more data I can provide, please ask.
> As the board is not in production use I can easily try out patches.

One patch you may want to apply it this one:
  http://lists.lm-sensors.org/pipermail/lm-sensors/2008-May/023189.html
It will let you switch the W83697HG chip from automatic fan speed
control to manual control and back - might be useful to investigate the
issue you have.

You can also give a try to the following patch, which is the equivalent
of the one I just posted for the it87 driver, but for the w83627hf
driver:

Subject: hwmon: (w83627hf) Filter out unlikely fan speed values

Filter out very large fan speed values. These can be reported by the
chip when a fan is being controlled at low speed. The tachometer
signal gets too weak and the chip fails to monitor the speed properly,
but unfortunately it reports unreasonably high values instead of 0
RPM, which is quite confusing.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
---
 drivers/hwmon/w83627hf.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- linux-2.6.26-rc4.orig/drivers/hwmon/w83627hf.c	2008-06-02 12:14:00.000000000 +0200
+++ linux-2.6.26-rc4/drivers/hwmon/w83627hf.c	2008-06-02 12:20:57.000000000 +0200
@@ -259,7 +259,7 @@ static inline u8 FAN_TO_REG(long rpm, in
 	if (rpm = 0)
 		return 255;
 	rpm = SENSORS_LIMIT(rpm, 1, 1000000);
-	return SENSORS_LIMIT((1350000 + rpm * div / 2) / (rpm * div), 1,
+	return SENSORS_LIMIT((1350000 + rpm * div / 2) / (rpm * div), 2,
 			     254);
 }
 
@@ -280,7 +280,8 @@ static int TEMP_FROM_REG(u8 reg)
         return (s8)reg * 1000;
 }
 
-#define FAN_FROM_REG(val,div) ((val)=0?-1:(val)=255?0:1350000/((val)*(div)))
+#define FAN_FROM_REG(val,div)	((val) <= 1 || (val) = 255 ? 0 : \
+				 1350000 / ((val) * (div)))
 
 #define PWM_TO_REG(val) (SENSORS_LIMIT((val),0,255))
 

It will report the missing fan speed values as 0, which is probably
slightly better than -1 and 337500, even though it doesn't really solve
the problem.

-- 
Jean Delvare
http://khali.linux-fr.org/wishlist.html

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

Re: [lm-sensors] [Bug?] W83697: Broken readings for fan speed 10%

[Bruno Prémont]

Hi Jean,

On Mon, 02 June 2008 Jean Delvare <khali@linux-fr.org> wrote:
> Hi Bruno,
> 
> On Sat, 31 May 2008 22:03:39 +0200, Bruno Prémont wrote:
> > On a Commell LE-365 I get readings for fan speed that are broken
> > about 10% of the time.
> > The board has a Winbond W83697 chip (I can't check the exact chip
> > name on the board as it's hidden by a heatsink, the photo from
> > Commell, as as well as the manual indicate a HG, the kenrel reports:
> >   [    3.572831] w83627hf: Found W83697HF chip at 0x290
> >   [    3.572831] WDT driver for the Winbond(TM) W83627HF/THF/HG
> > Super I/O chip initialising. [    3.572831] w83627hf/thf/hg WDT:
> > Watchdog already running. Resetting timeout to 60 sec
> > [    3.572831] w83627hf/thf/hg WDT: initialized. timeout` sec
> > (nowayout=0) )
> > 
> > Below a sample (reformatted) output of
> >   while sleep 1; do
> >     date;
> >     cat /sys/class/hwmon/hwmon0/device/fan1_input;
> >   done
> > :
> > Sat May 31 21:11:23 CEST 2008    2070
> > <snip>
> > Sat May 31 21:11:34 CEST 2008      -1
> > <snip>
> > Sat May 31 21:12:14 CEST 2008  337500
> > <snip>
> > 
> > The 337k RPM and -1 RPM do not make any sense.
> > I can't tell if this is a regression as I just started monitoring
> > a few sensor values (with older kernels I just did a few manual
> > checks but never noticed broken fan speeds)
> 
> I do not think this is a regression, most likely a hardware issue.
> 
> Is the fan's speed controlled in any way, either by the W83697HG chip,
> or maybe it is a self-regulated fan? Just check if the fan's speed
> increases with the temperature (i.e. with CPU load).

Yes, the fan has a built-in thermal sensor and regulates it's speed
based on temperature.
It's running either at its lowest speed or the speed just above.

> If this is the case, then please read this recent discussion the
> lm-sensors list:
>   http://marc.info/?l=lm-sensors&m\x121196069612940&w=2
> I suspect that your problem is similar.

That looks quite similar to what I'm seeing

> If the fan is not controlled and is running at full speed, then all I
> can think of is defective hardware (either the fan or the monitoring
> chip.)
> 
> > In case there is more data I can provide, please ask.
> > As the board is not in production use I can easily try out patches.
> 
> One patch you may want to apply it this one:
>   http://lists.lm-sensors.org/pipermail/lm-sensors/2008-May/023189.html
> It will let you switch the W83697HG chip from automatic fan speed
> control to manual control and back - might be useful to investigate
> the issue you have.

I will try this one, maybe the board is capable of doing speed control
but its not implemented in vanilla driver.
Until now setting pwm_enable to any values and changing PWM value did
not influence fan speed

The BIOS does not offer any speed control settings nor does it
configure the chip to do automatic speed control. (at least nothing
recognizable even with automatic-controlled fan)

> You can also give a try to the following patch, which is the
> equivalent of the one I just posted for the it87 driver, but for the
> w83627hf driver:
> 
> Subject: hwmon: (w83627hf) Filter out unlikely fan speed values
> 
> Filter out very large fan speed values. These can be reported by the
> chip when a fan is being controlled at low speed. The tachometer
> signal gets too weak and the chip fails to monitor the speed properly,
> but unfortunately it reports unreasonably high values instead of 0
> RPM, which is quite confusing.

I would prefer it to return the last valid speed if that speed is not
older than a few seconds though 0 is still better than "out of range".

I didn't look at the controlling circuit on the FAN to see how the
speed regulation may/may not influence the speed signal.

I will have a look at the tachometer with my oscilloscope (in the hope
the analog oscilloscope can display anything usable) to see how the
signal looks, comparing fixed-speed fan and the varying-speed fan at
different speeds.

I will also check fan behavior on IT8712F which is capable of doing PWM
control on 3 pin fans (maybe also automatic control, to be checked)


I will report back in the next days when I got around testing,
thanks for the pointers,
Bruno

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

Re: [lm-sensors] [Bug?] W83697: Broken readings for fan speed 10%

[Jean Delvare]

On Mon, 2 Jun 2008 21:09:41 +0200, Bruno Prémont wrote:
> On Mon, 02 June 2008 Jean Delvare <khali@linux-fr.org> wrote:
> > Is the fan's speed controlled in any way, either by the W83697HG chip,
> > or maybe it is a self-regulated fan? Just check if the fan's speed
> > increases with the temperature (i.e. with CPU load).
> 
> Yes, the fan has a built-in thermal sensor and regulates it's speed
> based on temperature.
> It's running either at its lowest speed or the speed just above.

Note that I've never seen this behavior on self-regulated fans... But I
guess it depends on the implementation.

> > (...)
> > One patch you may want to apply it this one:
> >   http://lists.lm-sensors.org/pipermail/lm-sensors/2008-May/023189.html
> > It will let you switch the W83697HG chip from automatic fan speed
> > control to manual control and back - might be useful to investigate
> > the issue you have.
> 
> I will try this one, maybe the board is capable of doing speed control
> but its not implemented in vanilla driver.

It is. The w83627hf driver can do manual fan speed control for a very
long time. What it is missing is support for automatic fan speed
control.

> Until now setting pwm_enable to any values and changing PWM value did
> not influence fan speed

If setting pwmN_enable to 1 and pwmN to 0 doesn't stop the fan, this
suggests that your motherboard can't do fan speed control. The easiest
way to test is by running the "pwmconfig" script. But anyway, you would
only have been able to slow down the fan, not speed it up, so it
wouldn't have solved the problem.

> > (...)
> > Filter out very large fan speed values. These can be reported by the
> > chip when a fan is being controlled at low speed. The tachometer
> > signal gets too weak and the chip fails to monitor the speed properly,
> > but unfortunately it reports unreasonably high values instead of 0
> > RPM, which is quite confusing.
> 
> I would prefer it to return the last valid speed if that speed is not
> older than a few seconds though 0 is still better than "out of range".

We just can't do that, it would be lying to the user. We can't tell the
user that his/her fan is spinning at a given speed when it might
actually be spinning way slower or even be plain stalled.

> (...)
> I will also check fan behavior on IT8712F which is capable of doing PWM
> control on 3 pin fans (maybe also automatic control, to be checked)

The IT8712F can control the fans in both manual and automatic modes,
but the it87 driver only supports the former. Keep in mind though that,
just because the chip can do it, a motherboard with this chip may not
support fan speed control; it all depends on how the motherboard is
wired.

-- 
Jean Delvare

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

Re: [lm-sensors] [Bug?] W83697: Broken readings for fan speed 10%

[Bruno Prémont]

On Mon, 02 June 2008 Jean Delvare <khali@linux-fr.org> wrote:
> On Mon, 2 Jun 2008 21:09:41 +0200, Bruno Prémont wrote:
> > On Mon, 02 June 2008 Jean Delvare <khali@linux-fr.org> wrote:
> > > Is the fan's speed controlled in any way, either by the W83697HG
> > > chip, or maybe it is a self-regulated fan? Just check if the
> > > fan's speed increases with the temperature (i.e. with CPU load).
> > 
> > Yes, the fan has a built-in thermal sensor and regulates it's speed
> > based on temperature.
> > It's running either at its lowest speed or the speed just above.
> 
> Note that I've never seen this behavior on self-regulated fans... But
> I guess it depends on the implementation.
> 
> > > (...)
> > > One patch you may want to apply it this one:
> > >   http://lists.lm-sensors.org/pipermail/lm-sensors/2008-May/023189.html
> > > It will let you switch the W83697HG chip from automatic fan speed
> > > control to manual control and back - might be useful to
> > > investigate the issue you have.
> > 
> > I will try this one, maybe the board is capable of doing speed
> > control but its not implemented in vanilla driver.
> 
> It is. The w83627hf driver can do manual fan speed control for a very
> long time. What it is missing is support for automatic fan speed
> control.
>
> > Until now setting pwm_enable to any values and changing PWM value
> > did not influence fan speed
> 
> If setting pwmN_enable to 1 and pwmN to 0 doesn't stop the fan, this
> suggests that your motherboard can't do fan speed control. The easiest
> way to test is by running the "pwmconfig" script. But anyway, you
> would only have been able to slow down the fan, not speed it up, so it
> wouldn't have solved the problem.

That's what I did, with a standard non-regulated fan and it did not
change behavior with pwmN_enable set to 1 and pwmN set to 0 or any
other value

So the motherboard probably does not support speed control (reason
for using self-controlled fan though on/off would still be nice).

> > > (...)
> > > Filter out very large fan speed values. These can be reported by
> > > the chip when a fan is being controlled at low speed. The
> > > tachometer signal gets too weak and the chip fails to monitor the
> > > speed properly, but unfortunately it reports unreasonably high
> > > values instead of 0 RPM, which is quite confusing.
> > 
> > I would prefer it to return the last valid speed if that speed is
> > not older than a few seconds though 0 is still better than "out of
> > range".
> 
> We just can't do that, it would be lying to the user. We can't tell
> the user that his/her fan is spinning at a given speed when it might
> actually be spinning way slower or even be plain stalled.

Returning 0 is not much better. The best would be to return an error
which client application could act on...

> > (...)
> > I will also check fan behavior on IT8712F which is capable of doing
> > PWM control on 3 pin fans (maybe also automatic control, to be
> > checked)
> 
> The IT8712F can control the fans in both manual and automatic modes,
> but the it87 driver only supports the former. Keep in mind though
> that, just because the chip can do it, a motherboard with this chip
> may not support fan speed control; it all depends on how the
> motherboard is wired.

My mainboard (IEI KINO-690S1) with IT8712F can do the speed control,
manual control is running properly (just that the range of values which
cause fan speed variations is not very intuitive: 0-2-4-6-8 from off to
full-speed for all the fans I tried, some also spin only for values
of at least 4)

The IT reports CPU temperature which is too low (offset? as curves
look very similar) - it's below room temperature (e.g. 20-24°C), AMD
Turion X2 sensor reports a temperature which makes more sense (e.g.
38-42°C)

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

Re: [lm-sensors] [Bug?] W83697: Broken readings for fan speed 10%

[Bruno Prémont]

Now I'm running 2.6.25.5 with both patches (the one changing
excessively large values to 0 and automatic fan control)

------ FAN connected to W83697HG ------
Looking at power and speed signals with an oscilloscope I get:
- slightly above 12V for FAN power
- speed square signal is about 11V at 62.5Hz

Both fan power and fan speed signal show a noise of about 0.1V in saw
shape ( |\|\|\|\ ) at 4kHz.

Changing value for pwm1_enable, pwm1_freq and pwm1 does not influence
the fan at all (no voltage variation, no variation in noise). So this
mainboard does not support FAN control :(

The W83697HG reports a speed of 1750 RPM though I think it's a slightly
high (Sticker on FAN says 1000RPM ... 2500RPM)

Connecting the FAN to the board's (LE-365) power-out connector produces
exactly the same results, thus the noise is generalized for the board's
"12V rail"
------ END ------

Note: after connecting a second (non-controlled) fan to the mainboard
(on second fan connector) the W83697HG stopped reporting the bad values
and did not start reporting them even after disconnecting the second fan
(no system shutdown/reboot during the whole testing)

The second FAN shows the same voltages, just with different frequency
for the speed signal.


------ FAN connected to IT8712F ------
(only speed sensor, power taken directly from system's power supply)

Looking at power and speed signals with an oscilloscope I get:
- slightly above 12V for FAN power
- speed square signal is about 5V at 55Hz

The IT8712F reports a speed of 4600 RPM though visually FAN does
not spin more quickly. 4600 RPM is definitely too much...

PS: This mainboard (IEI Kino690S) is capable to regulating FAN speed all
its fan connectors
------ END ------


I will look if I can find a way do determine the real fan speed in
order to compare with the values both chips report.
Looks like IT8712F (divisor = 2) reports a speed 3 times higher than
W83697HG (divisor = 4)

I guess the different voltages seen for both on speed line is due to
different resistors on the chips or the circuit in front of them.

Bruno


On Mon, 02 June 2008 Jean Delvare <khali@linux-fr.org> wrote:
> On Mon, 2 Jun 2008 21:09:41 +0200, Bruno Prémont wrote:
> > On Mon, 02 June 2008 Jean Delvare <khali@linux-fr.org> wrote:
> > > Is the fan's speed controlled in any way, either by the W83697HG
> > > chip, or maybe it is a self-regulated fan? Just check if the
> > > fan's speed increases with the temperature (i.e. with CPU load).
> > 
> > Yes, the fan has a built-in thermal sensor and regulates it's speed
> > based on temperature.
> > It's running either at its lowest speed or the speed just above.
> 
> Note that I've never seen this behavior on self-regulated fans... But
> I guess it depends on the implementation.
> 
> > > (...)
> > > One patch you may want to apply it this one:
> > >   http://lists.lm-sensors.org/pipermail/lm-sensors/2008-May/023189.html
> > > It will let you switch the W83697HG chip from automatic fan speed
> > > control to manual control and back - might be useful to
> > > investigate the issue you have.
> > 
> > I will try this one, maybe the board is capable of doing speed
> > control but its not implemented in vanilla driver.
> 
> It is. The w83627hf driver can do manual fan speed control for a very
> long time. What it is missing is support for automatic fan speed
> control.
> 
> > Until now setting pwm_enable to any values and changing PWM value
> > did not influence fan speed
> 
> If setting pwmN_enable to 1 and pwmN to 0 doesn't stop the fan, this
> suggests that your motherboard can't do fan speed control. The easiest
> way to test is by running the "pwmconfig" script. But anyway, you
> would only have been able to slow down the fan, not speed it up, so it
> wouldn't have solved the problem.
> 
> > > (...)
> > > Filter out very large fan speed values. These can be reported by
> > > the chip when a fan is being controlled at low speed. The
> > > tachometer signal gets too weak and the chip fails to monitor the
> > > speed properly, but unfortunately it reports unreasonably high
> > > values instead of 0 RPM, which is quite confusing.
> > 
> > I would prefer it to return the last valid speed if that speed is
> > not older than a few seconds though 0 is still better than "out of
> > range".
> 
> We just can't do that, it would be lying to the user. We can't tell
> the user that his/her fan is spinning at a given speed when it might
> actually be spinning way slower or even be plain stalled.
> 
> > (...)
> > I will also check fan behavior on IT8712F which is capable of doing
> > PWM control on 3 pin fans (maybe also automatic control, to be
> > checked)
> 
> The IT8712F can control the fans in both manual and automatic modes,
> but the it87 driver only supports the former. Keep in mind though
> that, just because the chip can do it, a motherboard with this chip
> may not support fan speed control; it all depends on how the
> motherboard is wired.
> 

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

Re: [lm-sensors] [Bug?] W83697: Broken readings for fan speed 10%

[Matt Roberds]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2520 bytes --]

On Sun, 8 Jun 2008, Bruno Prémont wrote:
> I will look if I can find a way do determine the real fan speed in
> order to compare with the values both chips report.

The exactly right instrument to use for this is probably an optical
tachometer.  It looks for reflections from a piece of reflective tape or
a white stripe painted on a rotating machine, and tells you the speed in
rpm.  If you're in university (or know someone who is), the physics or
mechanical engineering labs will often have such a device.
http://www.extech.com/instrument/products/451_499/461700.html is one
example but they are made by several companies.

There is another kind of tachometer that has a small wheel or probe that
you hold against the rotating machine; the machine spins the wheel and
the tachometer displays the rpm.  A computer fan motor is not very
strong, though, and making the measurement may tend to slow down the
fan.  http://www.extech.com/instrument/products/451_499/461750.html
is an example, but again, several companies make them.

The previous way to do this was with a stroboscope - a flashing light
with adjustable flash rate.  You point the light at the rotating machine
and turn a knob until the flashes of light "stop" the motion of the
machine.  You then read the flash rate from the knob and compute the
rpm.  http://www.ietlabs.com/Genrad/1531.html is a classic example.

If you have a function generator, you might be able to connect a LED to
its output and use it as a stroboscope.  (Make sure the output of the
function generator is strong enough to drive a LED; some of them are not
designed for this.)

Another way to do it is to use a plain old fluorescent lamp (with
magnetic ballast) or neon glow lamp.  Either one will flash at 100 Hz
(Europe) or 120 Hz (North America).  It may help to be in a dark room
with the fluorescent or neon lamp as the only source of illumination.
You can't adjust the flash rate, but you can use it to get an idea of
the fan speed.  For instance, if you mark one fan blade, and it appears
to "stop" in the same spot every time, the fan is probably turning at
6000 rpm (Europe): 100 Hz * 60 sec.  (It could also be turning at 12000
or 18000 or 24000 rpm, but most computer fans don't go that fast.)  If
the mark appears to "stop" in two places, 180 degrees apart, the fan is
probably turning at 3000 rpm, and so on.

Standard disclaimers apply; I don't get money or other consideration
from any companies mentioned.

Matt Roberds

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

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

Re: [lm-sensors] [Bug?] W83697: Broken readings for fan speed 10%

[Jean Delvare]

Hi Bruno,

On Sun, 8 Jun 2008 22:30:51 +0200, Bruno Prémont wrote:
> Now I'm running 2.6.25.5 with both patches (the one changing
> excessively large values to 0 and automatic fan control)
> 
> ------ FAN connected to W83697HG ------
> Looking at power and speed signals with an oscilloscope I get:
> - slightly above 12V for FAN power
> - speed square signal is about 11V at 62.5Hz
> 
> Both fan power and fan speed signal show a noise of about 0.1V in saw
> shape ( |\|\|\|\ ) at 4kHz.
> 
> Changing value for pwm1_enable, pwm1_freq and pwm1 does not influence
> the fan at all (no voltage variation, no variation in noise). So this
> mainboard does not support FAN control :(
> 
> The W83697HG reports a speed of 1750 RPM though I think it's a slightly
> high (Sticker on FAN says 1000RPM ... 2500RPM)

Most fans emit two pulses per revolution, so 62.5 Hz means 1875 RPM.
1750 RPM isn't too far away, so I'd say it's correct.

> Connecting the FAN to the board's (LE-365) power-out connector produces
> exactly the same results, thus the noise is generalized for the board's
> "12V rail"
> ------ END ------
> 
> Note: after connecting a second (non-controlled) fan to the mainboard
> (on second fan connector) the W83697HG stopped reporting the bad values
> and did not start reporting them even after disconnecting the second fan
> (no system shutdown/reboot during the whole testing)
> 
> The second FAN shows the same voltages, just with different frequency
> for the speed signal.
> 
> 
> ------ FAN connected to IT8712F ------
> (only speed sensor, power taken directly from system's power supply)
> 
> Looking at power and speed signals with an oscilloscope I get:
> - slightly above 12V for FAN power
> - speed square signal is about 5V at 55Hz
> 
> The IT8712F reports a speed of 4600 RPM though visually FAN does
> not spin more quickly. 4600 RPM is definitely too much...

I don't think you can judge the speed of a fan by just looking at it
(if you are a human being.) Your hears will tell you more than your
eyes about a fan's speed.

55 Hz would be 1650 RPM. If the IT8712F reports 4600 RPM then it's
indeed certainly wrong. Can you check what speed is reported in the
BIOS? Please also test with another fan if you can. I'd like to know if
that's a problem with this specific fan (in which case there's probably
not much we can do) or not. I suspect not (see below.)

> 
> PS: This mainboard (IEI Kino690S) is capable to regulating FAN speed all
> its fan connectors
> ------ END ------
> 
> 
> I will look if I can find a way do determine the real fan speed in
> order to compare with the values both chips report.
> Looks like IT8712F (divisor = 2) reports a speed 3 times higher than
> W83697HG (divisor = 4)

Please remember that the divisor value does _not_ divide the speed
value. It only affects the range of measurable values. For a fan that
could run as slow as 1000 RPM, you want to set the divider to 8.

> I guess the different voltages seen for both on speed line is due to
> different resistors on the chips or the circuit in front of them.

Can you tell us what revision of the IT8712F you have? The it87 driver
will write it to the kernel log when you load it. I would also like a
dump of the chip (using isadump).

Recent IT8712F chips have 16-bit tachometer registers, but the it87
driver doesn't support this mode for that chip yet. We received a patch
adding support for that 4 months ago:
  http://lists.lm-sensors.org/pipermail/lm-sensors/2008-February/022460.html
I reviewed it, it needed some more work, but the author never followed
up. If you need this, I guess we'll have to revive it.

-- 
Jean Delvare

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

Re: [lm-sensors] [Bug?] W83697: Broken readings for fan speed 10%

[Bruno Prémont]

Hi Jean,

On Wed, 11 June 2008 Jean Delvare <khali@linux-fr.org> wrote:
> Hi Bruno,
> 
> On Sun, 8 Jun 2008 22:30:51 +0200, Bruno Prémont wrote:
> > Now I'm running 2.6.25.5 with both patches (the one changing
> > excessively large values to 0 and automatic fan control)
> > 
> > ------ FAN connected to W83697HG ------
> > Looking at power and speed signals with an oscilloscope I get:
> > - slightly above 12V for FAN power
> > - speed square signal is about 11V at 62.5Hz
> > 
> > Both fan power and fan speed signal show a noise of about 0.1V in
> > saw shape ( |\|\|\|\ ) at 4kHz.
> > 
> > Changing value for pwm1_enable, pwm1_freq and pwm1 does not
> > influence the fan at all (no voltage variation, no variation in
> > noise). So this mainboard does not support FAN control :(
> > 
> > The W83697HG reports a speed of 1750 RPM though I think it's a
> > slightly high (Sticker on FAN says 1000RPM ... 2500RPM)
> 
> Most fans emit two pulses per revolution, so 62.5 Hz means 1875 RPM.
> 1750 RPM isn't too far away, so I'd say it's correct.

Ok, good to know that there are two pulses per revolution.
Need to verify the FAN's datasheet for temperature-speed mappings...

> > Connecting the FAN to the board's (LE-365) power-out connector
> > produces exactly the same results, thus the noise is generalized
> > for the board's "12V rail"
> > ------ END ------
> > 
> > Note: after connecting a second (non-controlled) fan to the
> > mainboard (on second fan connector) the W83697HG stopped reporting
> > the bad values and did not start reporting them even after
> > disconnecting the second fan (no system shutdown/reboot during the
> > whole testing)
> > 
> > The second FAN shows the same voltages, just with different
> > frequency for the speed signal.
> > 
> > 
> > ------ FAN connected to IT8712F ------
> > (only speed sensor, power taken directly from system's power supply)
> > 
> > Looking at power and speed signals with an oscilloscope I get:
> > - slightly above 12V for FAN power
> > - speed square signal is about 5V at 55Hz
> > 
> > The IT8712F reports a speed of 4600 RPM though visually FAN does
> > not spin more quickly. 4600 RPM is definitely too much...
> 
> I don't think you can judge the speed of a fan by just looking at it
> (if you are a human being.) Your hears will tell you more than your
> eyes about a fan's speed.

There is a sticker in the middle of the rotor of the fan, the
sticker not being properly centered one can compare quick and slow
based on how smoothed the sticker looks like, but sure ears cqn better
make distinction and eventually also determine the frequency if good
enough at music (+ knowing what frequency corresponds to what note)

> 55 Hz would be 1650 RPM. If the IT8712F reports 4600 RPM then it's
> indeed certainly wrong. Can you check what speed is reported in the
> BIOS? Please also test with another fan if you can. I'd like to know
> if that's a problem with this specific fan (in which case there's
> probably not much we can do) or not. I suspect not (see below.)

I've not checked the BIOS yet but increasing divider helps - see also
below

I have a second FAN of the same brand, same model which produces
equivalent values. I didn't check a quicker fixed-speed fan yet on that
connector.
The CPU fan is fixed-speed and regulated by IT8712F (speed
reported as 3200 with pwm=2 RPM, about 4400 RPM with pwm=4 - same values
for divider = 2..8)

By the way, how does this behave with S3 (suspend to RAM), are all
values reprogrammed by the kernel or is it userspace's job (can't test
because of the graphics chips... no resume support yet in kernel for
ATI/AMD graphics)
I know that on older nforce-based PC did forget pwm settings on resume
(never cared about the divider so would have to verify for that one)


> > 
> > PS: This mainboard (IEI Kino690S) is capable to regulating FAN
> > speed all its fan connectors
> > ------ END ------
> > 
> > 
> > I will look if I can find a way do determine the real fan speed in
> > order to compare with the values both chips report.
> > Looks like IT8712F (divisor = 2) reports a speed 3 times higher than
> > W83697HG (divisor = 4)
> 
> Please remember that the divisor value does _not_ divide the speed
> value. It only affects the range of measurable values. For a fan that
> could run as slow as 1000 RPM, you want to set the divider to 8.

Changing the divider to 8 makes the IT8712F report a likely speed around
1500 RPM, so the divider was the cause of the bad value.
(wondering why it defaults to such a small divider as is 2)


> > I guess the different voltages seen for both on speed line is due to
> > different resistors on the chips or the circuit in front of them.
> 
> Can you tell us what revision of the IT8712F you have? The it87 driver
> will write it to the kernel log when you load it. I would also like a
> dump of the chip (using isadump).

According to dmesg it's revision 8:
[   26.954326] i2c /dev entries driver
[   26.954524] it87: Found IT8712F chip at 0xe80, revision 8
[   26.954572] it87: in3 is VCC (+5V)
[   26.954611] it87: in7 is VCCH (+5V Stand-By)

Not sure how to call isadump to get the right data, its man-page
is reasonably vague regarding the addrreg and datareg args...
sould it be the following?:
  isadump 0xe85 0xe86

> Recent IT8712F chips have 16-bit tachometer registers, but the it87
> driver doesn't support this mode for that chip yet. We received a
> patch adding support for that 4 months ago:
>   http://lists.lm-sensors.org/pipermail/lm-sensors/2008-February/022460.html
> I reviewed it, it needed some more work, but the author never followed
> up. If you need this, I guess we'll have to revive it.

I could help testing that patch though test-responsiveness may not be
optimal knowing that this host is actively used and freeing a timeslot
for testing is not that easy (usually only possible at night during
weekend)

Bruno

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

Re: [lm-sensors] [Bug?] W83697: Broken readings for fan speed 10%

[Jean Delvare]

Hi Bruno,

On Wed, 11 Jun 2008 23:09:49 +0200, Bruno Prémont wrote:
> On Wed, 11 June 2008 Jean Delvare <khali@linux-fr.org> wrote:
> > 55 Hz would be 1650 RPM. If the IT8712F reports 4600 RPM then it's
> > indeed certainly wrong. Can you check what speed is reported in the
> > BIOS? Please also test with another fan if you can. I'd like to know
> > if that's a problem with this specific fan (in which case there's
> > probably not much we can do) or not. I suspect not (see below.)
> 
> I've not checked the BIOS yet but increasing divider helps - see also
> below

Your chip doesn't actually have these dividers. Changing them appears
to work because the driver _thinks_ the dividers exist and it somehow
compensates with the missing support for 16-bit counter registers. But
the value you get is still wrong!

> I have a second FAN of the same brand, same model which produces
> equivalent values. I didn't check a quicker fixed-speed fan yet on that
> connector.
> The CPU fan is fixed-speed and regulated by IT8712F (speed
> reported as 3200 with pwm=2 RPM, about 4400 RPM with pwm=4 - same values
> for divider = 2..8)
>
> By the way, how does this behave with S3 (suspend to RAM), are all
> values reprogrammed by the kernel or is it userspace's job (can't test
> because of the graphics chips... no resume support yet in kernel for
> ATI/AMD graphics)
> I know that on older nforce-based PC did forget pwm settings on resume
> (never cared about the divider so would have to verify for that one)

I've never thought about S3 support, so I'd say it is unsupported and
you are lucky if it works at all.

> > Please remember that the divisor value does _not_ divide the speed
> > value. It only affects the range of measurable values. For a fan that
> > could run as slow as 1000 RPM, you want to set the divider to 8.
> 
> Changing the divider to 8 makes the IT8712F report a likely speed around
> 1500 RPM, so the divider was the cause of the bad value.

No, it wasn't (not directly at least). That's two errors roughly
compensating themselves, so the end result looks acceptable, but it's
still wrong. I can explain it to you when you provide a dump of your
chip.

> (wondering why it defaults to such a small divider as is 2)

That's a problem on recent systems, indeed. I think the reason is
historical. When the first hardware monitoring chips made it into PCs,
in the late 90's, CPU fans had fixed speeds, in the 3000 to 4500 RPM
range. For this speed range, div=2 was the correct value. On recent
systems, we have fan spinning at variable speeds, and large case fans
that spin at low speeds too, so the default would rather be div=8 but
the chips were not updated for this. Some BIOSes switch the dividers to
8, though.

Note that chip manufacturers are switching to 12-bit or 16-bit fan
speed registers. That's the best way to address the problem of fans
with variable speed. Using a fixed, high divider value with an 8-bit
register would result in bad measurement resolution at higher speeds.

> > Can you tell us what revision of the IT8712F you have? The it87 driver
> > will write it to the kernel log when you load it. I would also like a
> > dump of the chip (using isadump).
> 
> According to dmesg it's revision 8:
> [   26.954326] i2c /dev entries driver
> [   26.954524] it87: Found IT8712F chip at 0xe80, revision 8
> [   26.954572] it87: in3 is VCC (+5V)
> [   26.954611] it87: in7 is VCCH (+5V Stand-By)

OK, revision 8 chips only support 16-bit fan speed registers, and the
driver doesn't support that. This is exactly what I suspected.

> Not sure how to call isadump to get the right data, its man-page
> is reasonably vague regarding the addrreg and datareg args...
> sould it be the following?:
>   isadump 0xe85 0xe86

Yes, that's exactly the right command to run in your case. See, the man
page wasn't that bad ;)

Please also tell me which of fan1, fan2 and fan3 is the case fan and
which is the CPU fan. Seeing the output of "sensors" on this machine
would help.

> > Recent IT8712F chips have 16-bit tachometer registers, but the it87
> > driver doesn't support this mode for that chip yet. We received a
> > patch adding support for that 4 months ago:
> >   http://lists.lm-sensors.org/pipermail/lm-sensors/2008-February/022460.html
> > I reviewed it, it needed some more work, but the author never followed
> > up. If you need this, I guess we'll have to revive it.
> 
> I could help testing that patch though test-responsiveness may not be
> optimal knowing that this host is actively used and freeing a timeslot
> for testing is not that easy (usually only possible at night during
> weekend)

I've asked the original author for an update, let's see if he sends
something.

-- 
Jean Delvare

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

Re: [lm-sensors] [Bug?] W83697: Broken readings for fan speed 10%

[Bruno Prémont]

Hi Jean,

On Thu, 12 June 2008 Jean Delvare <khali@linux-fr.org> wrote:
> Hi Bruno,
> 
> On Wed, 11 Jun 2008 23:09:49 +0200, Bruno Prémont wrote:
> > On Wed, 11 June 2008 Jean Delvare <khali@linux-fr.org> wrote:
> > > 55 Hz would be 1650 RPM. If the IT8712F reports 4600 RPM then it's
> > > indeed certainly wrong. Can you check what speed is reported in
> > > the BIOS? Please also test with another fan if you can. I'd like
> > > to know if that's a problem with this specific fan (in which case
> > > there's probably not much we can do) or not. I suspect not (see
> > > below.)
> > 
> > I've not checked the BIOS yet but increasing divider helps - see
> > also below
> 
> Your chip doesn't actually have these dividers. Changing them appears
> to work because the driver _thinks_ the dividers exist and it somehow
> compensates with the missing support for 16-bit counter registers. But
> the value you get is still wrong!

At least writing to the divider touches something and influences the result

> > By the way, how does this behave with S3 (suspend to RAM), are all
> > values reprogrammed by the kernel or is it userspace's job (can't
> > test because of the graphics chips... no resume support yet in
> > kernel for ATI/AMD graphics)
> > I know that on older nforce-based PC did forget pwm settings on
> > resume (never cared about the divider so would have to verify for
> > that one)
> 
> I've never thought about S3 support, so I'd say it is unsupported and
> you are lucky if it works at all.

Eventually I will look into this in the future, would be nice to keep/restore
alarms, divider, pwm settings and other configurations of chips on
resume (be it from S3/Suspend to RAM or from suspend to disk)


> > > Please remember that the divisor value does _not_ divide the speed
> > > value. It only affects the range of measurable values. For a fan
> > > that could run as slow as 1000 RPM, you want to set the divider
> > > to 8.
> > 
> > Changing the divider to 8 makes the IT8712F report a likely speed
> > around 1500 RPM, so the divider was the cause of the bad value.
> 
> No, it wasn't (not directly at least). That's two errors roughly
> compensating themselves, so the end result looks acceptable, but it's
> still wrong. I can explain it to you when you provide a dump of your
> chip.

So on my system the interpretation seems to change around div=3 or div=4
(at least for fan's current speed)

> Please also tell me which of fan1, fan2 and fan3 is the case fan and
> which is the CPU fan. Seeing the output of "sensors" on this machine
> would help.

# isadump 0xe85 0xe86
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: 11 10 00 00 00 00 00 00 00 80 40 1b 07 32 6c 02 
10: ff ff ff 33 83 01 02 40 00 00 00 ff ff ff ff ff 
20: 49 33 bc b6 4e 6f 5c b8 cc 14 2f 19 ba f1 f1 f1 
30: ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 
40: 7f ff 7f ff 7f ff ff ff 2d ff ff ff ff ff ff ff 
50: ff 23 7f 7f 7f 00 60 63 90 56 fd 12 00 00 00 00 
60: 7f 7f 7f 00 00 64 ff ff 7f 7f 7f 00 00 64 ff ff 
70: 7f 7f 7f 00 00 64 ff ff ff ff ff ff ff ff ff ff 
80: 00 00 00 00 ff ff ff ff 00 00 ff c0 02 00 99 99 
90: 7f 7f 7f 00 00 7f ff ff 7f 7f 7f 00 00 7f ff ff 
a0: 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff 
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

#sensors
k8temp-pci-00c3
Adapter: PCI adapter
Core0 Temp:  +38.0°C                                    
Core1 Temp:  +25.0°C                                    

it8712-isa-0e80
Adapter: ISA adapter
VCore 1:     +1.17 V  (min =  +0.00 V, max =  +4.08 V)
VCore 2:     +0.82 V  (min =  +0.00 V, max =  +4.08 V)
+3.3V:       +3.01 V  (min =  +0.00 V, max =  +4.08 V)
+5V:         +4.89 V  (min =  +0.00 V, max =  +6.85 V)
+12V:        +4.99 V  (min =  +0.00 V, max = +16.32 V)
-12V:       -13.74 V  (min = -27.36 V, max =  +3.93 V)
-5V:         -1.10 V  (min = -13.64 V, max =  +4.03 V)
Stdby:       +4.92 V  (min =  +0.00 V, max =  +6.85 V)
VBat:        +3.26 V
fan1:       3375 RPM  (min =    0 RPM, div = 8)
fan2:       1548 RPM  (min =    0 RPM, div = 8)
M/B Temp:    +20.0°C  (low  =  -1.0°C, high = +127.0°C)  sensor = thermal diode
CPU Temp:    +46.0°C  (low  =  -1.0°C, high = +127.0°C)  sensor = thermal diode
Temp3:       +25.0°C  (low  =  -1.0°C, high = +127.0°C)  sensor = transistor
cpu0_vid:   +1.550 V

fan1 = CPU fan
  (pwm1=2, pwm1_enable=1, pwm1_freq7500)
fan2 = artic cooling themperature controlled FAN
  (note: a drive-bay fan is controlled by pwm2 but has no
   tachometer - just in case the chip would make an assumption)
no fan 3 though pwm3 files exist

# sensors3.conf (only relevant part)
    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 "Stdby"
    label in8 "VBat"

    compute in3 ((6.8/10)+1)*@ ,  @/((6.8/10)+1)
    compute in4 ((30/10) +1)*@  , @/((30/10) +1)
    compute in5 (7.67 * @) - 27.36  ,  (@ + 27.36) / 7.67
    compute in6 (4.33 * @) - 13.64  ,  (@ + 13.64) / 4.33
    compute in7 ((6.8/10)+1)*@ ,  @/((6.8/10)+1)
    label temp1       "M/B Temp"
    label temp2       "CPU Temp"
    label temp3       "Temp3"
    set fan1_div 8
    set fan2_div 8

# Values reported by BIOS
CPU Temp: 33°C
System temp: 45°C
CPU FAN: 5769 RPM   (at max speed sensors driver says 5625 (peak 5818) with div=8)
Sys FAN: 1496 RPM   (sensors say 1520 with div=8)

CPU Core: 1.1V
+1.2V:   1.168V
+3.3V:   3.008V
+5V:     4.992V
+1.8V:   1.76V

> > > Recent IT8712F chips have 16-bit tachometer registers, but the
> > > it87 driver doesn't support this mode for that chip yet. We
> > > received a patch adding support for that 4 months ago:
> > >   http://lists.lm-sensors.org/pipermail/lm-sensors/2008-February/022460.html
> > > I reviewed it, it needed some more work, but the author never
> > > followed up. If you need this, I guess we'll have to revive it.
> > 
> > I could help testing that patch though test-responsiveness may not
> > be optimal knowing that this host is actively used and freeing a
> > timeslot for testing is not that easy (usually only possible at
> > night during weekend)
> 
> I've asked the original author for an update, let's see if he sends
> something.

I've seen the ping, lets see if he will answer

-
Bruno

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

Re: [lm-sensors] [Bug?] W83697: Broken readings for fan speed 10%

[Jean Delvare]

On Thu, 12 Jun 2008 20:37:54 +0200, Bruno Prémont wrote:
> On Thu, 12 June 2008 Jean Delvare <khali@linux-fr.org> wrote:
> > Your chip doesn't actually have these dividers. Changing them appears
> > to work because the driver _thinks_ the dividers exist and it somehow
> > compensates with the missing support for 16-bit counter registers. But
> > the value you get is still wrong!
> 
> At least writing to the divider touches something and influences the result

The problem is that you wrote to register bits marked as reserved in
the datasheet when you changed the divider values. Maybe they have the
same behavior of the older chips had, but maybe not. What is sure is
that the (current) driver will interpret things as if the register
meaning did not change. The result is undefined. This is the reason why
I told you shouldn't trust the values even if they appear to be
correct. It seems it works in your case, but we can't rely on it.

> (...)
> Eventually I will look into this in the future, would be nice to keep/restore
> alarms, divider, pwm settings and other configurations of chips on
> resume (be it from S3/Suspend to RAM or from suspend to disk)

Thinking about it, I see no reason why these settings would be lost on
suspend-to-ram. Suspend-to-disk certainly will need some care.

> So on my system the interpretation seems to change around div=3 or div=4
> (at least for fan's current speed)

There's no such thing as div=3, div values are always power of 2. But
yes, with a greater divider, the count result fits in 8 bits and this
gives you the correct fan speed. I didn't expect it.

> > Please also tell me which of fan1, fan2 and fan3 is the case fan and
> > which is the CPU fan. Seeing the output of "sensors" on this machine
> > would help.
> 
> # isadump 0xe85 0xe86
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00: 11 10 00 00 00 00 00 00 00 80 40 1b 07 32 6c 02 
> 10: ff ff ff 33 83 01 02 40 00 00 00 ff ff ff ff ff 
> 20: 49 33 bc b6 4e 6f 5c b8 cc 14 2f 19 ba f1 f1 f1 
> 30: ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 
> 40: 7f ff 7f ff 7f ff ff ff 2d ff ff ff ff ff ff ff 
> 50: ff 23 7f 7f 7f 00 60 63 90 56 fd 12 00 00 00 00 
> 60: 7f 7f 7f 00 00 64 ff ff 7f 7f 7f 00 00 64 ff ff 
> 70: 7f 7f 7f 00 00 64 ff ff ff ff ff ff ff ff ff ff 
> 80: 00 00 00 00 ff ff ff ff 00 00 ff c0 02 00 99 99 
> 90: 7f 7f 7f 00 00 7f ff ff 7f 7f 7f 00 00 7f ff ff 
> a0: 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff 
> b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
> c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
> d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
> e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
> f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

Thanks for the dump.

Looking at register 0x0c, I see that 16-bit mode is enabled for all of
fan1, fan2 and fan3. I also see that your attempt to set fan1_div and
fan2_div changed the value of register 0x0b (as is expected for older
chips) and apparently had some result (contrary to what I expected.)
Good to know that this is a possible workaround until the driver is
fixed. This won't work for fan3 though (the bit for fan3_div is used
for something else in the new chips.)

> 
> #sensors
> k8temp-pci-00c3
> Adapter: PCI adapter
> Core0 Temp:  +38.0°C                                    
> Core1 Temp:  +25.0°C                                    
> 
> it8712-isa-0e80
> Adapter: ISA adapter
> VCore 1:     +1.17 V  (min =  +0.00 V, max =  +4.08 V)
> VCore 2:     +0.82 V  (min =  +0.00 V, max =  +4.08 V)
> +3.3V:       +3.01 V  (min =  +0.00 V, max =  +4.08 V)
> +5V:         +4.89 V  (min =  +0.00 V, max =  +6.85 V)
> +12V:        +4.99 V  (min =  +0.00 V, max = +16.32 V)
> -12V:       -13.74 V  (min = -27.36 V, max =  +3.93 V)
> -5V:         -1.10 V  (min = -13.64 V, max =  +4.03 V)
> Stdby:       +4.92 V  (min =  +0.00 V, max =  +6.85 V)
> VBat:        +3.26 V
> fan1:       3375 RPM  (min =    0 RPM, div = 8)
> fan2:       1548 RPM  (min =    0 RPM, div = 8)
> M/B Temp:    +20.0°C  (low  =  -1.0°C, high = +127.0°C)  sensor = thermal diode
> CPU Temp:    +46.0°C  (low  =  -1.0°C, high = +127.0°C)  sensor = thermal diode
> Temp3:       +25.0°C  (low  =  -1.0°C, high = +127.0°C)  sensor = transistor
> cpu0_vid:   +1.550 V
> 
> fan1 = CPU fan
>   (pwm1=2, pwm1_enable=1, pwm1_freq7500)
> fan2 = artic cooling themperature controlled FAN
>   (note: a drive-bay fan is controlled by pwm2 but has no
>    tachometer - just in case the chip would make an assumption)
> no fan 3 though pwm3 files exist

The driver asks the chip which fan channels are enabled, and only
exposes the enabled ones (unless none is enabled, in which case it
enables them all.) We didn't implement the same for PWM outputs (yet).

How many fan headers does your motherboard have? And how many fans are
displayed in the BIOS? The driver code assumes, that, if the BIOS
enables some of the fan inputs, it will enable _all_ the inputs which
the motherboard is using. But it is possible that a BIOS enables just
the inputs it needs. If so, we'll have to revisit our strategy.

Now that you mention it, my own it87 chip only displays two fans, too,
while there are 3 fan headers on the board. I don't use the 3rd one
myself, but that's still a problem in general. I wonder if the BIOS
would enable it if there was a 3rd fan connected there.

> > I've asked the original author for an update, let's see if he sends
> > something.
> 
> I've seen the ping, lets see if he will answer

With this patch, you wouldn't have to care about fan clock divisors at
all, so it would be more comfortable.

-- 
Jean Delvare

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

Re: [lm-sensors] [Bug?] W83697: Broken readings for fan speed 10%

[Bruno Prémont]

On Fri, 13 June 2008 Jean Delvare <khali@linux-fr.org> wrote:
> > (...)
> > Eventually I will look into this in the future, would be nice to
> > keep/restore alarms, divider, pwm settings and other configurations
> > of chips on resume (be it from S3/Suspend to RAM or from suspend to
> > disk)
> 
> Thinking about it, I see no reason why these settings would be lost on
> suspend-to-ram. Suspend-to-disk certainly will need some care.

At least PWM settings got lost on the nforce I did try it on.

The only time I tried suspend on the it87 system I didn't check (and my
small daemon that regulates fan speeds based on CPU-temp [k8temp] and
hdd temps [hddtemp] took ower control anyhow as soon as userspace was no
more frozen - sidenote: I would appreciate if libsensors also knew
about PWM :))
I didn't have a look at other settings like limits and the like.
For reasonable testing I will have to wait for suspend/resume support
in framebuffer/drm for my AMD chipset's integrated graphics, the system
usually not being stable after resume


> > 
> > #sensors
> > k8temp-pci-00c3
> > Adapter: PCI adapter
> > Core0 Temp:  +38.0°C                                    
> > Core1 Temp:  +25.0°C                                    
> > 
> > it8712-isa-0e80
> > Adapter: ISA adapter
> > VCore 1:     +1.17 V  (min =  +0.00 V, max =  +4.08 V)
> > VCore 2:     +0.82 V  (min =  +0.00 V, max =  +4.08 V)
> > +3.3V:       +3.01 V  (min =  +0.00 V, max =  +4.08 V)
> > +5V:         +4.89 V  (min =  +0.00 V, max =  +6.85 V)
> > +12V:        +4.99 V  (min =  +0.00 V, max = +16.32 V)
> > -12V:       -13.74 V  (min = -27.36 V, max =  +3.93 V)
> > -5V:         -1.10 V  (min = -13.64 V, max =  +4.03 V)
> > Stdby:       +4.92 V  (min =  +0.00 V, max =  +6.85 V)
> > VBat:        +3.26 V
> > fan1:       3375 RPM  (min =    0 RPM, div = 8)
> > fan2:       1548 RPM  (min =    0 RPM, div = 8)
> > M/B Temp:    +20.0°C  (low  =  -1.0°C, high = +127.0°C)  sensor > > thermal diode CPU Temp:    +46.0°C  (low  =  -1.0°C, high > > +127.0°C)  sensor = thermal diode Temp3:       +25.0°C  (low  > > -1.0°C, high = +127.0°C)  sensor = transistor cpu0_vid:   +1.550 V
> > 
> > fan1 = CPU fan
> >   (pwm1=2, pwm1_enable=1, pwm1_freq7500)
> > fan2 = artic cooling themperature controlled FAN
> >   (note: a drive-bay fan is controlled by pwm2 but has no
> >    tachometer - just in case the chip would make an assumption)
> > no fan 3 though pwm3 files exist
> 
> The driver asks the chip which fan channels are enabled, and only
> exposes the enabled ones (unless none is enabled, in which case it
> enables them all.) We didn't implement the same for PWM outputs (yet).
> 
> How many fan headers does your motherboard have?
My motherboard has 2 fan headers

> And how many fans are displayed in the BIOS?
The BIOS shows just two as expected, fan1 (CPU) and fan2 (System):

# Values reported by BIOS
CPU Temp: 33°C
System temp: 45°C
CPU FAN: 5769 RPM
Sys FAN: 1496 RPM

CPU Core: 1.1V
+1.2V:   1.168V
+3.3V:   3.008V
+5V:     4.992V
+1.8V:   1.76V

> The driver code assumes, that, if the BIOS enables some of the fan
> inputs, it will enable _all_ the inputs which the motherboard is
> using. But it is possible that a BIOS enables just the inputs it
> needs. If so, we'll have to revisit our strategy.
> 
> Now that you mention it, my own it87 chip only displays two fans, too,
> while there are 3 fan headers on the board. I don't use the 3rd one
> myself, but that's still a problem in general. I wonder if the BIOS
> would enable it if there was a 3rd fan connected there.
> 
> > > I've asked the original author for an update, let's see if he
> > > sends something.
> > 
> > I've seen the ping, lets see if he will answer
> 
> With this patch, you wouldn't have to care about fan clock divisors at
> all, so it would be more comfortable.
Yes, without (possibly wrong) range-adjustment life is more comfortable.

Are there other changes between the driver's hardware knowledge and
revision 8?


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

Re: [lm-sensors] [Bug?] W83697: Broken readings for fan speed 10%

[Jean Delvare]

On Fri, 13 Jun 2008 23:31:54 +0200, Bruno Prémont wrote:
> sidenote: I would appreciate if libsensors also knew about PWM :))

This was discussed when designing libsensors 3.0.0 and we voted against
it, for the reason that PWM outputs are not sensors. The interface
needed to control fans is significantly different from what is needed
for sensors. Sensor limits are initialized once, while PWM values are
likely to evolve (based on temperature for example). Sensor values
often need scaling (in particular voltage) and giving them a proper
label is important. PWM values need no scaling factor and labelling
them doesn't sound too useful either. So the needs are clearly
different.

Also, it's easy to get things wrong (including permanent hardware
damage) when playing with PWM, while playing with sensors is normally
safe. So while it makes sense to have a sensors library for GUI apps to
interface with, I don't see a need for this for PWM. As a matter of
fact, our software fan control daemon is a simple bash script, it
doesn't need any library.

> Are there other changes between the driver's hardware knowledge and
> revision 8?

2 additional fans inputs, like the IT8716F and IT8718F have. Basically
the latest incarnations of the IT8712F have a lot in common with the
IT8716F. I don't get the point of ITE doing this, but they did, so
we'll have to support it. We add the missing features when users ask
for them... as you did.

-- 
Jean Delvare

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

Re: [lm-sensors] [Bug?] W83697: Broken readings for fan speed 10%

[Bruno Prémont]

On Mon, 02 June 2008 Jean Delvare <khali@linux-fr.org> wrote:
> One patch you may want to apply it this one:
>   http://lists.lm-sensors.org/pipermail/lm-sensors/2008-May/023189.html
> It will let you switch the W83697HG chip from automatic fan speed
> control to manual control and back - might be useful to investigate
> the issue you have.

For automatic fan speed control (not limited to this chip), how much
can automatic control be configured?

Some configuration options I do think about:
- temperature thresholds
  (e.g. to choose balance between cool and silent)
- link between temperature input and controlled fan

Are such features provided by the chips (chips of direct interest to me
are IT8712F, nforce420, [W83697HG])

Depending on what chips are capable of, how much of it does lm_sensors
implement and how is it expected to be used?

Bruno

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

Re: [lm-sensors] [Bug?] W83697: Broken readings for fan speed 10%

[Jean Delvare]

Hi Bruno,

On Sat, 14 Jun 2008 23:24:53 +0200, Bruno Prémont wrote:
> On Mon, 02 June 2008 Jean Delvare <khali@linux-fr.org> wrote:
> > One patch you may want to apply it this one:
> >   http://lists.lm-sensors.org/pipermail/lm-sensors/2008-May/023189.html
> > It will let you switch the W83697HG chip from automatic fan speed
> > control to manual control and back - might be useful to investigate
> > the issue you have.
> 
> For automatic fan speed control (not limited to this chip), how much
> can automatic control be configured?

Depends on the chip and driver, as you might have expected.

> Some configuration options I do think about:
> - temperature thresholds
>   (e.g. to choose balance between cool and silent)
> - link between temperature input and controlled fan
> 
> Are such features provided by the chips (chips of direct interest to me
> are IT8712F, nforce420, [W83697HG])

Have you read Documentation/hwmon/it87 and Documentation/hwmon/w83627hf
already? As far as I remember, both the it87 driver and the w83627hf
driver only allow switching from manual control to automatic control
and back. Neither gives control over the automatic mode settings. Both
families of chips can do it though, it's a driver issue.

I am not aware of the nforce420 having fan speed control capabilities.
If it does, we have no driver for it.

> Depending on what chips are capable of, how much of it does lm_sensors
> implement and how is it expected to be used?

For hardware-controlled fan speed, lm-sensors as a user-space package
doesn't matter. It's up to you to setup the chip in your BIOS (if it
allows this) or by writing to the driver's sysfs files (if it allows
this.)

For software-controlled fan speed, we have a little bash daemon named
fancontrol (and its helper configuration script named pwmconfig). This
should work with pretty much every hardware monitoring chip driver,
including it87 and w83627hf, and gives you control on temperature
thresholds and links between fan input, fan output and temperature
input channels.

-- 
Jean Delvare

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

Re: [lm-sensors] [Bug?] W83697: Broken readings for fan speed 10%

[Bruno Prémont]

[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]

On Sun, 15 June 2008 Jean Delvare <khali@linux-fr.org> wrote:
> Have you read Documentation/hwmon/it87 and
> Documentation/hwmon/w83627hf already? As far as I remember, both the
> it87 driver and the w83627hf driver only allow switching from manual
> control to automatic control and back. Neither gives control over
> the automatic mode settings. Both families of chips can do it though,
> it's a driver issue.

I just looked at those files, didn't remember looking there...

> I am not aware of the nforce420 having fan speed control capabilities.
> If it does, we have no driver for it.

Don't remember exactly for my nforce420 board, at least manual speed
settings work (have no seen it doing things automatically)

> For software-controlled fan speed, we have a little bash daemon named
> fancontrol (and its helper configuration script named pwmconfig). This
> should work with pretty much every hardware monitoring chip driver,
> including it87 and w83627hf, and gives you control on temperature
> thresholds and links between fan input, fan output and temperature
> input channels.

I saw the scripts tried them. As they did not really match what I
wanted I wrote a daemon (in C, attached) which has some more features:
 - sensor readings via libsensors
 - sensor reading from hddtemp
 - sensor reading via external script/binary
 - sensor reading from file

 - setting PWM depending on configured rules
   (a rule is if sensor > threshold => select PWM, if multiple rules
    are triggered, the one selecting highest PWM value wins)

Bruno

[-- Attachment #2: speedfan-0.4.tar.bz2 --]
[-- Type: application/x-bzip, Size: 19344 bytes --]

[-- Attachment #3: Type: text/plain, Size: 153 bytes --]

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