Hi,
after upgrading from 2.6.21 to 2.6.22 the CPU temperatures shown by
w83781d look unreal. They were in a range from 40?C when idle to
75?C under full load with 2.6.21. The values shown now are in a very
small range from 77?C to 82?C. From the (low) noise of the fan I can
tell that the temperature is <50?C.
The third temperature shown is completely wrong.
I have a Tyan Tiger MPX board with a w83782d chip. Output from
"sensors":
w83782d-i2c-0-2d
Adapter: SMBus AMD768 adapter at 80e0
+5 V: +4.81 V (min = +4.76 V, max = +5.24 V)
3 VSB: +3.30 V (min = +2.85 V, max = +3.15 V) ALARM
chs3 Fan: 2122 RPM (min = 2657 RPM, div = 4) ALARM
VRM2 Temp: -208?C (high = -176?C, hyst = -181?C) sensor = transistor
CPU1 Temp: +78.5?C (high = +80?C, hyst = +75?C) sensor = transistor ALARM
CPU2 Temp: +77.5?C (high = +80?C, hyst = +75?C) sensor = transistor ALARM
alarms:
beep_enable:
Sound alarm enabled
# cat /sys/bus/i2c/devices/0-002d/temp*_input
-209000
77500
77500
Any ideas?
-jo
--
-rw-r--r-- 1 jo users 62 2007-08-04 14:02 /home/jo/.signature
# Gigabyte GA-7IXE4
chip "w83782d-*"
# BIOS labels
label in0 "Vcore"
label in1 "Vcache"
label in2 "Vcc3"
label in3 "+5V"
label in4 "+12V"
label in5 "-12V"
label in6 "-5V"
label in7 "+5V SB"
label in8 "Battery"
# W83782D datasheet
compute in3 @ * (34 + 50) / 50 , @ * 50 / (34 + 50)
compute in4 @ * (28 + 10) / 10 , @ * 10 / (28 + 10)
compute in5 (@ - 3.6) * (232 + 56) / 56 + 3.6 , (@ - 3.6) * 56 / (232 + 56) + 3.6
compute in6 (@ - 3.6) * (120 + 56) / 56 + 3.6 , (@ - 3.6) * 56 / (120 + 56) + 3.6
compute in7 @ * (34 + 50) / 50 , @ * 50 / (34 + 50)
# Duron datasheet, VID. D3 = 1.6 +/- .1, D7 = 1.75 +/- .05 (but do 1.80 +/- 0.05)
set in0_min 1.75
set in0_max 1.85
# Duron datasheet, VCCA. D3 = D7 = 2.5 +/- .25
set in1_min 2.25
set in1_max 2.75
# Leave 10% for all
set in2_min 3.3 * 0.9
set in2_max 3.3 * 1.1
set in3_min 5.0 * 0.9
set in3_max 5.0 * 1.1
set in4_min 12.0 * 0.9
set in4_max 12.0 * 1.1
# 20 % for negative voltages
set in5_min -12.0 * 1.2
set in5_max -12.0 * 0.8
set in6_min -5.0 * 1.2
set in6_max -5.0 * 0.8
set in7_min 5.0 * 0.9
set in7_max 5.0 * 1.1
# 20% for battery
set in8_min 3.0 * 0.8
set in8_max 3.0 * 1.2
label temp1 "Sys Temp"
label temp2 "CPU Temp"
set temp1_over 55
set temp1_hyst 52
# Have temp2 (CPU) compliant with the BIOS readout
compute temp2 @-10,@+10
set temp2_over 60
set temp2_hyst 57
# Not connected
ignore temp3
label fan1 "Sys Fan"
label fan2 "CPU Fan"
label fan3 "Pow Fan"
set fan1_div 4 # min RPM = 1.35 x 10^6 / (div * 255) = 1323 (255 == max count)
set fan2_div 4 # min RPM = 1.35 x 10^6 / (div * 255) = 1323 (255 == max count)
set fan3_div 4 # min RPM = 1.35 x 10^6 / (div * 255) = 1323 (255 == max count)
set fan1_min 1500 * 0.9 # 1500 RPM fan
set fan2_min 2200 * 0.9 # 2200 RPM fan
# set fan3_min nnnn * 0.9 # nnnn RPM fan
# No readout on HD (Pow) fan
ignore fan3
# 0x000001: in0
# 0x000002: in1
# 0x000004: in2
# 0x000008: in3
# 0x000010: temp1
# 0x000020: temp2 (+temp3 on W83781D)
# 0x000040: fan1
# 0x000080: fan2
# 0x000100: in4
# 0x000200: in5
# 0x000400: in6
# 0x000800: fan3
# 0x001000: chassis
# 0x002000: temp3 (W83782D and W83627HF only)
# 0x010000: in7 (W83782D and W83627HF only)
# 0x020000: in8 (W83782D and W83627HF only)
set beeps 198655 # 0x0307ff
set beep_enable 1
Thanks for your reply.
the sensors.conf I'm currently using is provided by Tyan, so this seems
to be ok. One major difference that I can see: I don't have compute
statements for the CPU temperatures. If I use your config, I get 7.8?C
:-)
So there is definitely some difference in our hardware environment. OTOH
with the "right" compute statement the problem seems fixable.
BTW: there is another hwmon chip on the board, a w83627hf. Up to 2.6.21
this was managed by the w83781d driver, too. Now I use the w83627hf
driver (on the isa bus). No problem with that part.
-jo
On Sun, Aug 05, 2007 at 01:20:23PM +0200, Rene Herman wrote:
> On 08/05/2007 12:26 PM, Joerg Sommrey wrote:
>
> >after upgrading from 2.6.21 to 2.6.22 the CPU temperatures shown by
> >w83781d look unreal. They were in a range from 40?C when idle to
> >75?C under full load with 2.6.21. The values shown now are in a very
> >small range from 77?C to 82?C. From the (low) noise of the fan I can
> >tell that the temperature is <50?C.
> >The third temperature shown is completely wrong.
> >
> >I have a Tyan Tiger MPX board with a w83782d chip. Output from
> >"sensors":
> >
> >w83782d-i2c-0-2d
> >Adapter: SMBus AMD768 adapter at 80e0
>
> As a datapoint, the same W83782D on AMD756 (also I2C) works correctly with
> 2.6.22:
>
> w83782d-i2c-0-2d
> Adapter: SMBus AMD756 adapter at 50e0
>
> Jean Delvare recently worked on the ISA interface to these chips but it
> seems this would not be the cause if you are also using I2C. Our hardware
> appears rather identical...
>
> I've attached (an excerpt of) my /etc/sensors.conf -- I once dug through
> the datasheets for those compute lines for example so perhaps its still
> useful even if 2.6.21 working for you probably means you don't have a
> config problem.
>
> Rene.
>
Hi Joerg:
(I tried to follow-up using the gmane.org mail/news gateway... didn't seem
to work.)
* Joerg Sommrey <[email protected]> [2007-08-05 12:26:04 +0200]:
> Hi,
>
> after upgrading from 2.6.21 to 2.6.22 the CPU temperatures shown by
> w83781d look unreal. They were in a range from 40?C when idle to
> 75?C under full load with 2.6.21. The values shown now are in a very
> small range from 77?C to 82?C. From the (low) noise of the fan I can
> tell that the temperature is <50?C.
> The third temperature shown is completely wrong.
>
> I have a Tyan Tiger MPX board with a w83782d chip. Output from
> "sensors":
>
> w83782d-i2c-0-2d
> Adapter: SMBus AMD768 adapter at 80e0
> +5 V: +4.81 V (min = +4.76 V, max = +5.24 V)
> 3 VSB: +3.30 V (min = +2.85 V, max = +3.15 V) ALARM
> chs3 Fan: 2122 RPM (min = 2657 RPM, div = 4) ALARM
> VRM2 Temp: -208?C (high = -176?C, hyst = -181?C) sensor = transistor
> CPU1 Temp: +78.5?C (high = +80?C, hyst = +75?C) sensor = transistor ALARM
> CPU2 Temp: +77.5?C (high = +80?C, hyst = +75?C) sensor = transistor ALARM
> alarms:
> beep_enable:
> Sound alarm enabled
>
> # cat /sys/bus/i2c/devices/0-002d/temp*_input
> -209000
> 77500
> 77500
>
> Any ideas?
Please run the following commands as root (against both kernel versions) and
reply-to-all with the results:
# modprobe i2c-dev
# i2cdump -y 0 0x2d b 0 0x4e
# i2cdump -y 0 0x48
# i2cdump -y 0 0x49
Also, can you confirm that you're using the sensors.conf from here:
http://www.tyan.com/support_download_utility.aspx?model=s.s2466
Finally, can you confirm that "sensors -s" is running (without error) some
time during system startup, w/ both kernel versions?
Thanks & regards,
--
Mark M. Hoffman
[email protected]
Hi Mark,
just to eliminate as many impacts as possible, I did:
- reinstall the unmodified sensors.conf from Tyan's support page
- power off before rebooting
A call to "sensors -s" is done without errors in all cases.
The module parameters I use currently with both kernels:
options w83781d force_w83782d=0,0x2d force_subclients=0,0x2d,0x48,0x49
options w83627hf force_addr=0x0c00
When I first realized the problem, I didn't use w83627hf yet. Results
are the same when w83781d is used as driver for w83627hf.
Parameters in that case just from Tyan:
options w83781d force_w83782d=0,0x2d force_subclients=0,0x2d,0x48,0x49 force_w83627hf=0,0x2c force_subclients=0,0x2c,0x4a,0x4b init=0
"My" i2cdump doesn't accept an -y option, maybe a Debianism. Results
see below.
TIA
-jo
### 2.6.21 ###############################
Script started on Wed Aug 8 16:53:10 2007
bear:~/hwmon# i2cdump 0 0x2d b 0 0x4e
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x2d, mode byte
You have five seconds to reconsider and press CTRL-C!
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
20: 6c 6b 70 b4 4d 9a ce 3b ff ff f3 80 67 80 67 d8 lkp?M??;..??g?g?
30: c4 c3 b0 d9 b2 41 06 c5 b2 50 4b fa aa 40 00 00 ?????A???PK??@..
40: 01 ec 2f 00 00 00 00 54 2d 02 10 44 01 95 00 a3 ??/....T-??D??.?
50: ff ff 00 ff ff ff 00 80 30 00 ff ff 11 0e ff ff .......?0...??..
60: 6b 6a 70 b3 4d 9b ce 3b ff ff f3 80 67 80 67 d8 kjp?M??;..??g?g?
70: c4 c3 b0 d9 b2 41 06 c5 b2 50 4b fa aa 40 00 00 ?????A???PK??@..
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
a0: 6b 6a 70 b4 4c 9a ce 3b ff ff f5 80 67 80 67 d8 kjp?L??;..??g?g?
b0: c4 c3 b0 d9 b2 41 06 c5 b2 50 4b fa aa 40 00 00 ?????A???PK??@..
c0: 01 00 00 00 00 00 00 54 2d 02 10 44 01 95 00 a3 ?......T-??D??.?
d0: ff ff 00 ff ff ff 00 80 30 00 ff ff 11 0e ff ff .......?0...??..
e0: 6b 6a 6f b1 4d 9a ce 3b ff ff f5 80 67 80 67 d8 kjo?M??;..??g?g?
f0: c4 c3 b0 d9 b2 41 06 c5 b2 50 4b fa aa 40 00 00 ?????A???PK??@..
bear:~/hwmon# i2cdump 0 0x48
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x48, mode byte
You have five seconds to reconsider and press CTRL-C!
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 ;.KP;.KP;.KP;.KP
10: 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 ;.KP;.KP;.KP;.KP
20: 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 ;.KP;.KP;.KP;.KP
30: 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 ;.KP;.KP;.KP;.KP
40: 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 ;.KP;.KP;.KP;.KP
50: 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 ;.KP;.KP;.KP;.KP
60: 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 ;.KP;.KP;.KP;.KP
70: 3b 00 4b 50 3a 00 4b 50 3a 00 4b 50 3b 00 4b 50 ;.KP:.KP:.KP;.KP
80: 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 ;.KP;.KP;.KP;.KP
90: 3b 00 4b 50 3a 00 4b 50 3a 00 4b 50 3b 00 4b 50 ;.KP:.KP:.KP;.KP
a0: 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 ;.KP;.KP;.KP;.KP
b0: 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 ;.KP;.KP;.KP;.KP
c0: 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 ;.KP;.KP;.KP;.KP
d0: 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 ;.KP;.KP;.KP;.KP
e0: 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 3b 00 4b 50 ;.KP;.KP;.KP;.KP
f0: 3a 00 4b 50 3a 00 4b 50 3b 00 4b 50 3b 00 4b 50 :.KP:.KP;.KP;.KP
bear:~/hwmon# i2cdump 0 0x49
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x49, mode byte
You have five seconds to reconsider and press CTRL-C!
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 38 00 4b 50 38 00 4b 50 38 00 4b 50 38 00 4b 50 8.KP8.KP8.KP8.KP
10: 38 00 4b 50 38 00 4b 50 38 00 4b 50 38 00 4b 50 8.KP8.KP8.KP8.KP
20: 38 00 4b 50 38 00 4b 50 38 00 4b 50 38 00 4b 50 8.KP8.KP8.KP8.KP
30: 38 00 4b 50 38 00 4b 50 38 00 4b 50 38 00 4b 50 8.KP8.KP8.KP8.KP
40: 38 00 4b 50 38 00 4b 50 38 00 4b 50 38 00 4b 50 8.KP8.KP8.KP8.KP
50: 38 00 4b 50 38 00 4b 50 38 00 4b 50 38 00 4b 50 8.KP8.KP8.KP8.KP
60: 38 00 4b 50 38 00 4b 50 38 00 4b 50 38 00 4b 50 8.KP8.KP8.KP8.KP
70: 38 00 4b 50 38 00 4b 50 38 00 4b 50 38 00 4b 50 8.KP8.KP8.KP8.KP
80: 38 00 4b 50 38 00 4b 50 38 00 4b 50 38 00 4b 50 8.KP8.KP8.KP8.KP
90: 38 00 4b 50 38 00 4b 50 38 00 4b 50 38 00 4b 50 8.KP8.KP8.KP8.KP
a0: 38 00 4b 50 38 00 4b 50 38 00 4b 50 38 00 4b 50 8.KP8.KP8.KP8.KP
b0: 38 00 4b 50 38 00 4b 50 38 00 4b 50 38 00 4b 50 8.KP8.KP8.KP8.KP
c0: 38 00 4b 50 38 00 4b 50 38 00 4b 50 38 00 4b 50 8.KP8.KP8.KP8.KP
d0: 38 00 4b 50 38 00 4b 50 38 00 4b 50 38 00 4b 50 8.KP8.KP8.KP8.KP
e0: 38 00 4b 50 38 00 4b 50 38 00 4b 50 38 00 4b 50 8.KP8.KP8.KP8.KP
f0: 38 00 4b 50 38 00 4b 50 38 00 4b 50 38 00 4b 50 8.KP8.KP8.KP8.KP
bear:~/hwmon# sensors
w83782d-i2c-0-2d
Adapter: SMBus AMD768 adapter at 80e0
AGP V: +1.74 V (min = +3.14 V, max = +3.46 V) ALARM
+5 V: +4.81 V (min = +4.73 V, max = +5.24 V)
DDR V: +1.23 V (min = +2.85 V, max = +3.47 V) ALARM
3 VSB: +3.30 V (min = +2.85 V, max = +3.15 V) ALARM
Bat V: +0.00 V (min = +2.64 V, max = +3.95 V) ALARM
chs1 Fan: 0 RPM (min = 2700 RPM, div = 2) ALARM
chs2 Fan: 0 RPM (min = 3970 RPM, div = 2) ALARM
chs3 Fan: 0 RPM (min = 10546 RPM, div = 2) ALARM
VRM2 Temp: +56 C (high = +80 C, hyst = +75 C) sensor = transistor
CPU1 Temp: +57.5 C (high = +80 C, hyst = +75 C) sensor = transistor
CPU2 Temp: +56.0 C (high = +80 C, hyst = +75 C) sensor = transistor
alarms:
beep_enable:
Sound alarm enabled
w83627hf-isa-0c00
Adapter: ISA adapter
VCore1: +1.73 V (min = +1.66 V, max = +1.84 V)
VCore2: +1.73 V (min = +1.66 V, max = +1.84 V)
+3.3 V: +3.33 V (min = +3.14 V, max = +3.47 V)
+12 V: +11.83 V (min = +13.21 V, max = +10.83 V) ALARM
-12 V: -12.11 V (min = -13.18 V, max = -10.80 V)
CPU1 Fan: 4041 RPM (min = 4687 RPM, div = 2) ALARM
CPU2 Fan: 4192 RPM (min = 6750 RPM, div = 2) ALARM
VRM1 Temp: +44 C (high = -124 C, hyst = +16 C) sensor = transistor ALARM
AGP Temp: +50.0 C (high = +80 C, hyst = +75 C) sensor = transistor
DDR Temp: +46.0 C (high = +80 C, hyst = +75 C) sensor = transistor
alarms: Chassis intrusion detection ALARM
beep_enable:
Sound alarm disabled
bear:~/hwmon# exit
exit
Script done on Wed Aug 8 16:55:02 2007
### 2.6.22 ###############################
Script started on Wed Aug 8 16:41:41 2007
bear:~/hwmon# i2cdump 0 0x2d b 0 0x4e
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x2d, mode byte
You have five seconds to reconsider and press CTRL-C!
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
20: 6c 6b 70 b3 4c 9a ce 3b ff ff ff 80 67 80 67 d9 lkp?L??;...?g?g?
30: c4 c3 b1 d9 b2 41 06 c5 b2 50 4b fa aa 40 00 00 ?????A???PK??@..
40: 01 ec 2f 00 00 00 00 54 2d 02 10 44 01 95 00 a3 ??/....T-??D??.?
50: ff ff 00 ff ff ff 00 80 30 60 ff ff 11 02 ff ff .......?0`..??..
60: 6c 6b 6f b3 4c 9a ce 3b ff ff ff 80 67 80 67 d9 lko?L??;...?g?g?
70: c4 c3 b1 d9 b2 41 06 c5 b2 50 4b fa aa 40 00 00 ?????A???PK??@..
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
a0: 6c 6b 6f b4 4c 9b ce 3b ff ff ff 80 67 80 67 d9 lko?L??;...?g?g?
b0: c4 c3 b1 d9 b2 41 06 c5 b2 50 4b fa aa 40 00 00 ?????A???PK??@..
c0: 01 08 00 00 00 00 00 54 2d 02 10 44 01 95 00 a3 ??.....T-??D??.?
d0: ff ff 00 ff ff ff 00 80 30 60 ff ff 11 02 ff ff .......?0`..??..
e0: 6b 6a 6f b4 4c 9a ce 3b ff ff ff 80 67 80 67 d9 kjo?L??;...?g?g?
f0: c4 c3 b1 d9 b2 41 06 c5 b2 50 4b fa aa 40 00 00 ?????A???PK??@..
bear:~/hwmon# i2cdump 0 0x48
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x48, mode byte
You have five seconds to reconsider and press CTRL-C!
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 50 00 4b 50 50 00 4b 50 50 00 4b 50 50 00 4b 50 P.KPP.KPP.KPP.KP
10: 50 00 4b 50 50 00 4b 50 50 00 4b 50 50 00 4b 50 P.KPP.KPP.KPP.KP
20: 50 00 4b 50 50 00 4b 50 50 00 4b 50 50 00 4b 50 P.KPP.KPP.KPP.KP
30: 50 00 4b 50 50 00 4b 50 50 00 4b 50 50 00 4b 50 P.KPP.KPP.KPP.KP
40: 50 00 4b 50 50 00 4b 50 50 00 4b 50 50 00 4b 50 P.KPP.KPP.KPP.KP
50: 50 00 4b 50 50 00 4b 50 50 00 4b 50 50 00 4b 50 P.KPP.KPP.KPP.KP
60: 50 00 4b 50 50 00 4b 50 50 00 4b 50 50 00 4b 50 P.KPP.KPP.KPP.KP
70: 50 00 4b 50 50 00 4b 50 50 00 4b 50 50 00 4b 50 P.KPP.KPP.KPP.KP
80: 50 00 4b 50 50 00 4b 50 50 00 4b 50 50 00 4b 50 P.KPP.KPP.KPP.KP
90: 50 00 4b 50 50 00 4b 50 50 00 4b 50 50 00 4b 50 P.KPP.KPP.KPP.KP
a0: 50 00 4b 50 4f 00 4b 50 50 00 4b 50 50 00 4b 50 P.KPO.KPP.KPP.KP
b0: 50 00 4b 50 50 00 4b 50 50 00 4b 50 50 00 4b 50 P.KPP.KPP.KPP.KP
c0: 50 00 4b 50 50 00 4b 50 50 00 4b 50 50 00 4b 50 P.KPP.KPP.KPP.KP
d0: 50 00 4b 50 50 00 4b 50 50 00 4b 50 50 00 4b 50 P.KPP.KPP.KPP.KP
e0: 50 00 4b 50 50 00 4b 50 4f 00 4b 50 4f 00 4b 50 P.KPP.KPO.KPO.KP
f0: 50 00 4b 50 50 00 4b 50 50 00 4b 50 50 00 4b 50 P.KPP.KPP.KPP.KP
bear:~/hwmon# i2cdump 0 0x49
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x49, mode byte
You have five seconds to reconsider and press CTRL-C!
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 O.KPO.KPO.KPO.KP
10: 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 O.KPO.KPO.KPO.KP
20: 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 O.KPO.KPO.KPO.KP
30: 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 O.KPO.KPO.KPO.KP
40: 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 O.KPO.KPO.KPO.KP
50: 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 O.KPO.KPO.KPO.KP
60: 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 O.KPO.KPO.KPO.KP
70: 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 O.KPO.KPO.KPO.KP
80: 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 O.KPO.KPO.KPO.KP
90: 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 O.KPO.KPO.KPO.KP
a0: 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 O.KPO.KPO.KPO.KP
b0: 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 O.KPO.KPO.KPO.KP
c0: 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 O.KPO.KPO.KPO.KP
d0: 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 O.KPO.KPO.KPO.KP
e0: 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 O.KPO.KPO.KPO.KP
f0: 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 4f 00 4b 50 O.KPO.KPO.KPO.KP
bear:~/hwmon# sensors
w83782d-i2c-0-2d
Adapter: SMBus AMD768 adapter at 80e0
AGP V: +1.73 V (min = +3.14 V, max = +3.47 V) ALARM
+5 V: +4.81 V (min = +4.76 V, max = +5.24 V)
DDR V: +1.22 V (min = +2.85 V, max = +3.47 V) ALARM
3 VSB: +3.30 V (min = +2.85 V, max = +3.15 V) ALARM
Bat V: +0.00 V (min = +2.64 V, max = +3.95 V) ALARM
chs1 Fan: 0 RPM (min = 2700 RPM, div = 2) ALARM
chs2 Fan: 0 RPM (min = 3970 RPM, div = 2) ALARM
chs3 Fan: 0 RPM (min = 10546 RPM, div = 2) ALARM
VRM2 Temp: +56 C (high = +80 C, hyst = +75 C) sensor = transistor
CPU1 Temp: +79.5 C (high = +80 C, hyst = +75 C) sensor = transistor ALARM
CPU2 Temp: +79.5 C (high = +80 C, hyst = +75 C) sensor = transistor ALARM
alarms:
beep_enable:
Sound alarm enabled
w83627hf-isa-0c00
Adapter: ISA adapter
VCore1: +1.71 V (min = +1.66 V, max = +1.84 V)
VCore2: +1.71 V (min = +1.66 V, max = +1.84 V)
+3.3 V: +3.33 V (min = +3.14 V, max = +3.47 V)
+12 V: +11.83 V (min = +13.21 V, max = +10.83 V) ALARM
-12 V: -12.20 V (min = -13.18 V, max = -10.80 V)
CPU1 Fan: 4041 RPM (min = 4687 RPM, div = 2) ALARM
CPU2 Fan: 4166 RPM (min = 6750 RPM, div = 2) ALARM
VRM1 Temp: +43 C (high = -124 C, hyst = +16 C) sensor = transistor ALARM
AGP Temp: +49.5 C (high = +80 C, hyst = +75 C) sensor = transistor
DDR Temp: +46.0 C (high = +80 C, hyst = +75 C) sensor = transistor
alarms: Chassis intrusion detection ALARM
beep_enable:
Sound alarm disabled
bear:~/hwmon# exit
Script done on Wed Aug 8 16:43:20 2007
On Tue, Aug 07, 2007 at 09:03:16PM -0400, Mark M. Hoffman wrote:
> Hi Joerg:
>
> (I tried to follow-up using the gmane.org mail/news gateway... didn't seem
> to work.)
>
> * Joerg Sommrey <[email protected]> [2007-08-05 12:26:04 +0200]:
> > Hi,
> >
> > after upgrading from 2.6.21 to 2.6.22 the CPU temperatures shown by
> > w83781d look unreal. They were in a range from 40?C when idle to
> > 75?C under full load with 2.6.21. The values shown now are in a very
> > small range from 77?C to 82?C. From the (low) noise of the fan I can
> > tell that the temperature is <50?C.
> > The third temperature shown is completely wrong.
> >
> > I have a Tyan Tiger MPX board with a w83782d chip. Output from
> > "sensors":
> >
> > w83782d-i2c-0-2d
> > Adapter: SMBus AMD768 adapter at 80e0
> > +5 V: +4.81 V (min = +4.76 V, max = +5.24 V)
> > 3 VSB: +3.30 V (min = +2.85 V, max = +3.15 V) ALARM
> > chs3 Fan: 2122 RPM (min = 2657 RPM, div = 4) ALARM
> > VRM2 Temp: -208?C (high = -176?C, hyst = -181?C) sensor = transistor
> > CPU1 Temp: +78.5?C (high = +80?C, hyst = +75?C) sensor = transistor ALARM
> > CPU2 Temp: +77.5?C (high = +80?C, hyst = +75?C) sensor = transistor ALARM
> > alarms:
> > beep_enable:
> > Sound alarm enabled
> >
> > # cat /sys/bus/i2c/devices/0-002d/temp*_input
> > -209000
> > 77500
> > 77500
> >
> > Any ideas?
>
> Please run the following commands as root (against both kernel versions) and
> reply-to-all with the results:
>
> # modprobe i2c-dev
> # i2cdump -y 0 0x2d b 0 0x4e
> # i2cdump -y 0 0x48
> # i2cdump -y 0 0x49
>
> Also, can you confirm that you're using the sensors.conf from here:
> http://www.tyan.com/support_download_utility.aspx?model=s.s2466
>
> Finally, can you confirm that "sensors -s" is running (without error) some
> time during system startup, w/ both kernel versions?
>
> Thanks & regards,
>
> --
> Mark M. Hoffman
> [email protected]
>
Hi Joerg:
* Joerg Sommrey <[email protected]> [2007-08-08 17:17:16 +0200]:
> Hi Mark,
>
> just to eliminate as many impacts as possible, I did:
> - reinstall the unmodified sensors.conf from Tyan's support page
> - power off before rebooting
>
> A call to "sensors -s" is done without errors in all cases.
> The module parameters I use currently with both kernels:
>
> options w83781d force_w83782d=0,0x2d force_subclients=0,0x2d,0x48,0x49
> options w83627hf force_addr=0x0c00
>
> When I first realized the problem, I didn't use w83627hf yet. Results
> are the same when w83781d is used as driver for w83627hf.
> Parameters in that case just from Tyan:
>
> options w83781d force_w83782d=0,0x2d force_subclients=0,0x2d,0x48,0x49 force_w83627hf=0,0x2c force_subclients=0,0x2c,0x4a,0x4b init=0
>
> "My" i2cdump doesn't accept an -y option, maybe a Debianism. Results
> see below.
Newer i2cdump skips the 5-second warning when given -y, that's all.
> ### 2.6.21 ###############################
> Script started on Wed Aug 8 16:53:10 2007
> bear:~/hwmon# i2cdump 0 0x2d b 0 0x4e
(snip tons of results)
Thanks for sending all that. I see one bug clearly, and I'm pretty close to
seeing the other one. But for tonight, I need sleep.
In the meantime, please try this command as root, against the newer kernel,
*after* you've done 'sensors -s':
# i2cset -f 0 0x2d 0x5d 0x0e b
Wait > 2 seconds for the hardware to update itself, then run 'sensors' again.
I'm pretty sure you'll see the correct temps.
Regards,
--
Mark M. Hoffman
[email protected]
Hi Mark,
On Wed, Aug 08, 2007 at 11:56:42PM -0400, Mark M. Hoffman wrote:
> Hi Joerg:
>
> * Joerg Sommrey <[email protected]> [2007-08-08 17:17:16 +0200]:
> > Hi Mark,
> >
> > just to eliminate as many impacts as possible, I did:
> > - reinstall the unmodified sensors.conf from Tyan's support page
> > - power off before rebooting
> >
> > A call to "sensors -s" is done without errors in all cases.
> > The module parameters I use currently with both kernels:
> >
> > options w83781d force_w83782d=0,0x2d force_subclients=0,0x2d,0x48,0x49
> > options w83627hf force_addr=0x0c00
> >
> > When I first realized the problem, I didn't use w83627hf yet. Results
> > are the same when w83781d is used as driver for w83627hf.
> > Parameters in that case just from Tyan:
> >
> > options w83781d force_w83782d=0,0x2d force_subclients=0,0x2d,0x48,0x49 force_w83627hf=0,0x2c force_subclients=0,0x2c,0x4a,0x4b init=0
> >
> > "My" i2cdump doesn't accept an -y option, maybe a Debianism. Results
> > see below.
>
> Newer i2cdump skips the 5-second warning when given -y, that's all.
>
> > ### 2.6.21 ###############################
> > Script started on Wed Aug 8 16:53:10 2007
> > bear:~/hwmon# i2cdump 0 0x2d b 0 0x4e
>
> (snip tons of results)
>
> Thanks for sending all that. I see one bug clearly, and I'm pretty close to
> seeing the other one. But for tonight, I need sleep.
>
> In the meantime, please try this command as root, against the newer kernel,
> *after* you've done 'sensors -s':
>
> # i2cset -f 0 0x2d 0x5d 0x0e b
>
> Wait > 2 seconds for the hardware to update itself, then run 'sensors' again.
> I'm pretty sure you'll see the correct temps.
The displayed temperatures changed to 67.5?C / 66.0?C. Still, this seems to
be too high. The power supply's fan runs too slow for such CPU
temperatures. In older kernels it becomes noisy above 50?C.
Under load the temperatures shown are around 95?C, way too high.
-jo
--
-rw-r--r-- 1 jo users 62 2007-08-08 21:06 /home/jo/.signature
Hi Joerg:
> On Wed, Aug 08, 2007 at 11:56:42PM -0400, Mark M. Hoffman wrote:
> > Thanks for sending all that. I see one bug clearly, and I'm pretty close to
> > seeing the other one. But for tonight, I need sleep.
There's just one bug after all. The second was a figment of my sleep-deprived
imagination.
> > In the meantime, please try this command as root, against the newer kernel,
> > *after* you've done 'sensors -s':
> >
> > # i2cset -f 0 0x2d 0x5d 0x0e b
> >
> > Wait > 2 seconds for the hardware to update itself, then run 'sensors' again.
> > I'm pretty sure you'll see the correct temps.
* Joerg Sommrey <[email protected]> [2007-08-09 09:09:15 +0200]:
> The displayed temperatures changed to 67.5?C / 66.0?C. Still, this seems to
> be too high. The power supply's fan runs too slow for such CPU
> temperatures. In older kernels it becomes noisy above 50?C.
>
> Under load the temperatures shown are around 95?C, way too high.
My bad, there's a second i2cset command that would have done it. Please try
this patch against v2.6.22.
* * * * *
commit a3333f720da3a173153b00cebc129c48cd3a40af
Author: Mark M. Hoffman <[email protected]>
Date: Thu Aug 9 08:12:46 2007 -0400
hwmon: fix w83781d temp sensor type setting
Commit 348753379a7704087603dad403603e825422fd9a introduced a regression that
caused temp2 and temp3 sensor type settings to be written to temp1 instead.
The result is that temp sensor readings could be way off.
Signed-off-by: Mark M. Hoffman <[email protected]>
diff --git a/drivers/hwmon/w83781d.c b/drivers/hwmon/w83781d.c
index f85b48f..c95909c 100644
--- a/drivers/hwmon/w83781d.c
+++ b/drivers/hwmon/w83781d.c
@@ -740,9 +740,9 @@ store_sensor(struct device *dev, struct device_attribute *da,
static SENSOR_DEVICE_ATTR(temp1_type, S_IRUGO | S_IWUSR,
show_sensor, store_sensor, 0);
static SENSOR_DEVICE_ATTR(temp2_type, S_IRUGO | S_IWUSR,
- show_sensor, store_sensor, 0);
+ show_sensor, store_sensor, 1);
static SENSOR_DEVICE_ATTR(temp3_type, S_IRUGO | S_IWUSR,
- show_sensor, store_sensor, 0);
+ show_sensor, store_sensor, 2);
/* I2C devices get this name attribute automatically, but for ISA devices
we must create it by ourselves. */
--
Mark M. Hoffman
[email protected]
Hi Mark,
On Thu, Aug 09, 2007 at 08:26:19AM -0400, Mark M. Hoffman wrote:
> Hi Joerg:
>
> > On Wed, Aug 08, 2007 at 11:56:42PM -0400, Mark M. Hoffman wrote:
> > > Thanks for sending all that. I see one bug clearly, and I'm pretty close to
> > > seeing the other one. But for tonight, I need sleep.
>
> There's just one bug after all. The second was a figment of my sleep-deprived
> imagination.
>
[...]
>
> My bad, there's a second i2cset command that would have done it. Please try
> this patch against v2.6.22.
>
Great, problem fixed. Thanks a lot for your prompt solution!
-jo
--
-rw-r--r-- 1 jo users 62 2007-08-09 08:46 /home/jo/.signature
On Thu, 9 Aug 2007 08:26:19 -0400, Mark M. Hoffman wrote:
> Author: Mark M. Hoffman <[email protected]>
> Date: Thu Aug 9 08:12:46 2007 -0400
>
> hwmon: fix w83781d temp sensor type setting
>
> Commit 348753379a7704087603dad403603e825422fd9a introduced a regression that
> caused temp2 and temp3 sensor type settings to be written to temp1 instead.
> The result is that temp sensor readings could be way off.
>
> Signed-off-by: Mark M. Hoffman <[email protected]>
Good catch, sorry for messing up. My test chip is a W83781D, it doesn't
have thermal sensor type selection, so I couldn't test that.
Acked-by: Jean Delvare <[email protected]>
> diff --git a/drivers/hwmon/w83781d.c b/drivers/hwmon/w83781d.c
> index f85b48f..c95909c 100644
> --- a/drivers/hwmon/w83781d.c
> +++ b/drivers/hwmon/w83781d.c
> @@ -740,9 +740,9 @@ store_sensor(struct device *dev, struct device_attribute *da,
> static SENSOR_DEVICE_ATTR(temp1_type, S_IRUGO | S_IWUSR,
> show_sensor, store_sensor, 0);
> static SENSOR_DEVICE_ATTR(temp2_type, S_IRUGO | S_IWUSR,
> - show_sensor, store_sensor, 0);
> + show_sensor, store_sensor, 1);
> static SENSOR_DEVICE_ATTR(temp3_type, S_IRUGO | S_IWUSR,
> - show_sensor, store_sensor, 0);
> + show_sensor, store_sensor, 2);
>
> /* I2C devices get this name attribute automatically, but for ISA devices
> we must create it by ourselves. */
--
Jean Delvare