I've had this motherboard since January 2011 had never gotten fan control to work. It seems to be either a driver or hardware implementation issue. It doesn't appear to have the atk0110 acpi methods of hardware control. When i try to echo any numbers into pwm_{1..3} they do not actually write to the ?file?/?register?
I hadn't looked too deeply into it, so as to understand the ACPI/ATK0110 vs legacy W83667HG-B control until recently. About as far as i had gotten previously was to read http://www.lm-sensors.org/wiki/AsusFormulaHacking.
Recently started looking further into it for a variety of reasons; I am now sure that my board does not have any ATK0110 devices on it:
Details:
Kernel information
Linux BigBox 3.4.9-gentoo #1 SMP Sat Oct 20 21:41:06 PDT 2012 x86_64 Intel(R) Core(TM) i3 CPU 540 @ 3.07GHz GenuineIntel GNU/Linux
Modprobe of atk shows nothing in dmesg
BigBox w83627ehf.656 # modprobe asus-atk0110
dylan@BigBox ~/My_Utils/acpi $ lsmod | grep asus
asus_atk0110 8614 0
BigBox w83627ehf.656 # dmesg | tail -3
[ 51.000276] w83627ehf: Found W83667HG-B chip at 0x290
[ 57.806564] eth0: no IPv6 routers present
[ 69.009033] netlink: 12 bytes leftover after parsing attributes.
dsdt.dsl does not have any of the 'key' atk stuff in it from the above mentioned webpage:
dylan@BigBox ~/My_Utils/acpi $ grep -i -e asoc -e vbuf -e v500 -e v12v dsdt.dsl
dylan@BigBox ~/My_Utils/acpi $
I don't have no-apci on my kernel command line, there are no conflicts listed for acpi in dmesg, and the drivers for the sensor chip load happily
dylan@BigBox ~/My_Utils/acpi $ cat /proc/cmdline
root=/dev/md3
dylan@BigBox ~/My_Utils/acpi $ dmesg | grep w83627ehf
[ 51.000276] w83627ehf: Found W83667HG-B chip at 0x290
dylan@BigBox ~/My_Utils/acpi $
dylan@BigBox ~/My_Utils/acpi $ dmesg | grep conflict
dylan@BigBox ~/My_Utils/acpi $
dylan@BigBox ~/My_Utils/acpi $ sensors w83667hg-isa-0290
w83667hg-isa-0290
Adapter: ISA adapter
Vcore: +0.89 V (min = +0.60 V, max = +1.50 V)
in1: +1.73 V (min = +1.50 V, max = +1.88 V)
AVCC: +3.38 V (min = +2.98 V, max = +3.63 V)
+3.3V: +3.38 V (min = +2.98 V, max = +3.63 V)
in4: +1.67 V (min = +1.50 V, max = +1.83 V)
in5: +1.69 V (min = +1.76 V, max = +2.04 V) ALARM
in6: +1.49 V (min = +1.34 V, max = +1.65 V)
3VSB: +3.38 V (min = +2.98 V, max = +3.63 V)
Vbat: +3.31 V (min = +2.70 V, max = +3.30 V) ALARM
Rear_Fan: 3590 RPM (min = 888 RPM, div = 8)
CPU_Fan: 1854 RPM (min = 2678 RPM, div = 8) ALARM
HD_Fan0: 3590 RPM (min = 1298 RPM, div = 8)
HD_Fan1: 3668 RPM (min = 865 RPM, div = 8)
fan5: 0 RPM (min = 10546 RPM, div = 128) ALARM
PECI Agent 1: +6.0°C (high = +60.0°C, hyst = +58.0°C) sensor = Intel PECI
PECI Agent 1: +6.0°C (high = +89.0°C, hyst = +88.0°C) sensor = Intel PECI
SYSTIN: +22.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor
CPUTIN: -54.0°C
cpu0_vid: +0.000 V
intrusion0: OK
In Bios the fans are set to 'no control / full speed' (i've tried in other modes too)
Now, as root.. i can change the settings in pwm_enable (following doc for kernel driver for values)
BigBox w83627ehf.656 # head *_enable
==> pwm1_enable <==
1
==> pwm2_enable <==
1
==> pwm3_enable <==
1
BigBox w83627ehf.656 # for i in $(seq 3); do echo 2 >pwm${i}_enable; done
BigBox w83627ehf.656 # head *_enable
==> pwm1_enable <==
2
==> pwm2_enable <==
2
==> pwm3_enable <==
2
As root I can also change the values for pwm_mode
BigBox w83627ehf.656 # head *_mode
==> pwm1_mode <==
1
==> pwm2_mode <==
1
==> pwm3_mode <==
1
BigBox w83627ehf.656 # for i in $(seq 3); do echo 0 >pwm${i}_mode; done
BigBox w83627ehf.656 # head *_mode
==> pwm1_mode <==
0
==> pwm2_mode <==
0
==> pwm3_mode <==
0
But i cannot change the pwm{1..3} values themselves..
BigBox w83627ehf.656 # head pwm{1..3}
==> pwm1 <==
255
==> pwm2 <==
255
==> pwm3 <==
255
BigBox w83627ehf.656 # for i in $(seq 3); do echo 0 >pwm${i}; done
BigBox w83627ehf.656 # head pwm{1..3}
==> pwm1 <==
255
==> pwm2 <==
255
==> pwm3 <==
255
There don't appear to be any errors, etc.
According to some threads in a bug on speedfan, there are some major problem with the W83667HG-B datasheet -- but i can't figure out how to contact/ask for what the bugs were...
I saw some other bug with lm-sensors developers helping debug a similar issue with isadump. Is that a possibility in this situation?
Help or thoughts or suggestions?
Thanks!!
_______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
