[lm-sensors] W83627DHG, steps to use

[lm-sensors] W83627DHG, steps to use

[Andrew Gaydenko]

Hi!

I'm absolutely new with lm_sensors. After digging in the mail list and the
site, I suppose, steps to use W83627DHG with Core 2 Duo look like shown
below. Is this list correct?


Thanks in advance!
Andrew

_______

Step 1. adding 'coretemp' kernel module

Apply kernel patch referenced at this message:

http://lists.lm-sensors.org/pipermail/lm-sensors/2006-December/018420.html

It seems like this is last 'coretemp' module version. I have begun from the
http://www.lm-sensors.org/wiki/Devices list, have found coretemp ref here
http://lists.lm-sensors.org/pipermail/lm-sensors/2006-October/018100.html
and followed 'coretemp' subjects at the mailing list till '2006-December'


Step 2. patching 'w83627ehf' kernel module

Apply this

http://khali.linux-fr.org/devel/linux-2.6/jdelvare-hwmon/hwmon-w83627ehf-add-w83627dhg-support.patch

kernel patch which is referenced also here http://www.lm-sensors.org/wiki/Devices


Step 3. getting and building last lm_sensors from SVN tree (self-explaned).

Step 4. play with lm_sensors.conf file and frontends (self-explaned).

[lm-sensors] W83627DHG, steps to use

[Andrew Gaydenko]

OK, being waiting for answer, I have tried to patch a kernel. Patching
was OK (except for rejecting in ./Documentation/...). Kernel making gives:

...
Kernel: arch/x86_64/boot/bzImage is ready  (#25)
  Building modules, stage 2.
  MODPOST 165 modules
WARNING: "msr_read" [drivers/hwmon/coretemp.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

.config contains this row: CONFIG_X86_MSR=y I have tried to see
all 'msr_read' occurences, 'grep 'msr_read' -R /usr/src/linux-2.6.19-w-r2/*'
output is:

Binary file /usr/src/linux-2.6.19-w-r2/arch/x86_64/kernel/msr.o matches
Binary file /usr/src/linux-2.6.19-w-r2/arch/x86_64/kernel/built-in.o matches
/usr/src/linux-2.6.19-w-r2/arch/i386/kernel/msr.c:static ssize_t msr_read(struct file *file, char __user * buf,
/usr/src/linux-2.6.19-w-r2/arch/i386/kernel/msr.c:      .read = msr_read,
Binary file /usr/src/linux-2.6.19-w-r2/arch/i386/kernel/msr.o matches
/usr/src/linux-2.6.19-w-r2/drivers/hwmon/coretemp.c:            msr_read(data->id, MSR_IA32_THERM_STATUS, &eax, &edx);
/usr/src/linux-2.6.19-w-r2/drivers/hwmon/coretemp.c:            err = msr_read(data->id, 0xee, &eax, &edx);
/usr/src/linux-2.6.19-w-r2/drivers/hwmon/coretemp.c:    err = msr_read(data->id, MSR_IA32_THERM_STATUS, &eax, &edx);
Binary file /usr/src/linux-2.6.19-w-r2/drivers/hwmon/coretemp.o matches
/usr/src/linux-2.6.19-w-r2/System.map:ffffffff8026b3d0 t msr_read
Binary file /usr/src/linux-2.6.19-w-r2/vmlinux matches

Where is my failt? 
gentoo-sources-2.6.19-r2 kernel tree is in use.


Andrew

[lm-sensors] W83627DHG, steps to use

[David Hubbard]

Hi Andrew,

I'm working on the w83627ehf module (which supports the w83627dhg
chip). I can tell you that the coretemp module is for your Core 2 Duo.
The Core 2 Duo reports digital temperatures directly to the coretemp
module, and does not involve the w83627dhg. As you know, the coretemp
module is new. It hasn't even been added to the linux/drivers/hwmon
directory (as of 2.6.20-rc2.

> OK, being waiting for answer, I have tried to patch a kernel. Patching
> was OK (except for rejecting in ./Documentation/...). Kernel making gives:

The reason the patch does not apply correctly to 2.6.19-rc2 is because
the patch is meant for 2.6.20-rc1 or later. There were changes to the
file linux/Documentation/hwmon/w83627ehf that are part of 2.6.20-rc1.
You should be OK ignoring the patch error unless you encounter
problems. Then you should update to a 2.6.20 kernel and start from
there. If the patch doesn't apply cleanly to 2.6.20-rc1, then I'd be
interested to find out why.

> WARNING: "msr_read" [drivers/hwmon/coretemp.ko] undefined!

The latest coretemp sources might fix this. I believe Rudolf Marek is
still discussing the details of the RDMSR and WRMSR instructions with
H. Peter Anvin and Alan Cox. That is why you get the error. The code
might compile OK on a 2.6.18 kernel, since Rudolf wrote the code for
that kernel.

More information:
- thread http://lists.lm-sensors.org/pipermail/lm-sensors/2006-December/018438.html
- message http://lists.lm-sensors.org/pipermail/lm-sensors/2006-December/018443.html

> gentoo-sources-2.6.19-r2 kernel tree is in use.

Thanks for providing enough info (i.e. the kernel version) so I can
make some guesses.

Again, I'm not the one who wrote coretemp, and it's not in a finished
state. So, there will be no official support until the driver is
submitted in final form. In the mean time, happy hacking!

David

[lm-sensors] W83627DHG, steps to use

[Andrew Gaydenko]

Hi, David!

==== On Thursday 28 December 2006 09:59, you wrote: ===...
>
>More information:
>- thread http://lists.lm-sensors.org/pipermail/lm-sensors/2006-December/018438.html
>- message http://lists.lm-sensors.org/pipermail/lm-sensors/2006-December/018443.html
>
...

OK, as for coretemp - will wait. 

I have applied the W83627DHG patch, all sensors works (THANKS!) except for +5V
(it shows something about 0.384V). So, I can stay with CPU temp from W83627DHG.
But what does this sensor show? First CPU temp? Second one? I mean Core 2 Duo.

Another problem is, when I try pwmconfig, I get such error:

Testing pwm control 9191-0290/pwm2 ...
  9191-0290/fan2_input ... speed was 1721 now 1713
/usr/sbin/pwmconfig: line 102: echo: write error: Invalid argument

It is for current SVN tree. So, I don't know a reason why pwm doesn't work - is 
this disabled by BIOS, or is this the script error? I'm not shell guru :-)


Thanks!
Andrew

[lm-sensors] W83627DHG, steps to use

[David Hubbard]

Hi Andrew,

> I have applied the W83627DHG patch, all sensors works (THANKS!) except for +5V
> (it shows something about 0.384V). So, I can stay with CPU temp from
>  W83627DHG. But what does this sensor show? First CPU temp?
> Second one? I mean Core 2 Duo.

The w83627dhg has three temperature input pins. (SYSTIN, CPUTIN,
AUXTIN) However, the motherboard manufacturer can wire the pins any
way they want. When you discover what each pin is wired to, you can
update your sensors.conf and send an email to us letting us know what
your motherboard is and what customizations you did. The Core 2 Duo
should have four sensors, if it's like my Athlon 64 X2. That is, there
are two digital sensors (one per core) which the coretemp driver will
read. And there are two analog sensors (one per core) which the
motherboard might connect to the w83627dhg. Use cpuburn or something
you prefer and see which temperatures increase.

> Another problem is, when I try pwmconfig, I get such error:
>
> Testing pwm control 9191-0290/pwm2 ...
>   9191-0290/fan2_input ... speed was 1721 now 1713
> /usr/sbin/pwmconfig: line 102: echo: write error: Invalid argument
>
> It is for current SVN tree. So, I don't know a reason why pwm doesn't work - is
> this disabled by BIOS, or is this the script error? I'm not shell guru :-)

I'm going to pass on this one. Rudolf?

David

[lm-sensors] W83627DHG, steps to use

[Andrew Gaydenko]

==== On Friday 29 December 2006 05:32, you wrote: ===>Hi Andrew,
>
>> I have applied the W83627DHG patch, all sensors works (THANKS!) except for +5V
>> (it shows something about 0.384V). So, I can stay with CPU temp from
>>  W83627DHG. But what does this sensor show? First CPU temp?
>> Second one? I mean Core 2 Duo.
>
>The w83627dhg has three temperature input pins. (SYSTIN, CPUTIN,
>AUXTIN) However, the motherboard manufacturer can wire the pins any
>way they want. When you discover what each pin is wired to, you can
>update your sensors.conf and send an email to us letting us know what
>your motherboard is and what customizations you did. The Core 2 Duo
>should have four sensors, if it's like my Athlon 64 X2. That is, there
>are two digital sensors (one per core) which the coretemp driver will
>read. And there are two analog sensors (one per core) which the
>motherboard might connect to the w83627dhg. Use cpuburn or something
>you prefer and see which temperatures increase.

AUX Temp doesn't change at all when both CPU are under heavy loading.
The sensor value is 119C always (it is for ASUS P5B-VM motherboard).

>
>> Another problem is, when I try pwmconfig, I get such error:
>>
>> Testing pwm control 9191-0290/pwm2 ...
>>   9191-0290/fan2_input ... speed was 1721 now 1713
>> /usr/sbin/pwmconfig: line 102: echo: write error: Invalid argument
>>
>> It is for current SVN tree. So, I don't know a reason why pwm doesn't work - is
>> this disabled by BIOS, or is this the script error? I'm not shell guru :-)
>
>I'm going to pass on this one. Rudolf?
>
>David

I think script is correct. I have tried 'echo 0' > blablabla and got the same
error. Given pwm2_enable has content "1". 'echo 1' doesn't lead to error.

P.S. Must I use multiple "To:" in accordance with msg header, or must I answer
     to the mailing list only? (I use last variant now)


Andrew

[lm-sensors] W83627DHG, steps to use

[David Hubbard]

Hi Andrew,

> AUX Temp doesn't change at all when both CPU are under heavy loading.
> The sensor value is 119C always (it is for ASUS P5B-VM motherboard).

Does this mean that SYSTIN also doesn't change? If so, only one of the
cores has been wired to the w83627dhg.

> >I'm going to pass on this one. Rudolf?
>
> I think script is correct. I have tried 'echo 0' > blablabla and got the same
> error. Given pwm2_enable has content "1". 'echo 1' doesn't lead to error.

The script is incorrect. The reason the driver returns an error for
'echo 0' is because the value 0 is invalid for this chip. The script
should handle the error correctly and not display an error.

Setting pwmX_enable to 0 is supposed to disable the pwm output for
that fan, resulting in the maximum fan speed. The w83627ehf and
w83627dhg do not have a way to disable the pwm output. Just write 255
to pwmX.

> P.S. Must I use multiple "To:" in accordance with msg header, or must I answer
>      to the mailing list only? (I use last variant now)

The reason for including specific people in To: is so we know that you
wanted us to read your message. We sometimes don't respond if you just
post to the list, even though we are subscribed to the list.

David

[lm-sensors] W83627DHG, steps to use

[Andrew Gaydenko]

Hi, David,

==== On Friday 29 December 2006 06:09, you wrote: ===>> AUX Temp doesn't change at all when both CPU are under heavy loading.
>> The sensor value is 119C always (it is for ASUS P5B-VM motherboard).
>
>Does this mean that SYSTIN also doesn't change? If so, only one of the
>cores has been wired to the w83627dhg.

No, it doesn't. 'SYS Temp' slightly changes in 49-52C range, in accordance
with BIOS monitor. Besides zalman for CPU there are two addtional silent
fans connected to 12V directly (well, via serial resistors). Probably this
is a reason for so small 'SYS Temp' changing range (BTW, I'm not an 
overcolcoker, my aim is a silence :-))

>Setting pwmX_enable to 0 is supposed to disable the pwm output for
>that fan, resulting in the maximum fan speed. The w83627ehf and
>w83627dhg do not have a way to disable the pwm output. Just write 255
>to pwmX.

OK, I'm tracing for SVN tree :-)

>
>> P.S. Must I use multiple "To:" in accordance with msg header, or must I answer
>>      to the mailing list only? (I use last variant now)
>
>The reason for including specific people in To: is so we know that you
>wanted us to read your message. We sometimes don't respond if you just
>post to the list, even though we are subscribed to the list.

I think the first rule is to avoid flooding of mail boxes. OK, I'll use all
"To:" fields for answers (and is ready to reduce to the mailing list only :-)).


Andrew

[lm-sensors] W83627DHG, steps to use

[Luca]

On 12/28/06, Andrew Gaydenko <a at gaydenko.com> wrote:
> Hi, David!
>
> ==== On Thursday 28 December 2006 09:59, you wrote: ===> >
> >More information:
> >- thread http://lists.lm-sensors.org/pipermail/lm-sensors/2006-December/018438.html
> >- message http://lists.lm-sensors.org/pipermail/lm-sensors/2006-December/018443.html
> >
> ...
>
> OK, as for coretemp - will wait.

Btw, using /dev/cpuX/msr device you can read core temperatures, I just
copied the algorithm used by the kernel driver. Of course it's not
integrated with the rest of the hwmon subsystem...
If you're interested I can send you the source file as soon as I get
back to home.

Luca

[lm-sensors] W83627DHG, steps to use

[David Hubbard]

Hi Rudolf,

It looks like there is some code in the kernel that could be extended
to provide MSR data for the coretemp driver--maybe you already know
about this?

> Btw, using /dev/cpuX/msr device you can read core temperatures, I just
> copied the algorithm used by the kernel driver. Of course it's not
> integrated with the rest of the hwmon subsystem...
> If you're interested I can send you the source file as soon as I get
> back to home.
>
> Luca

David

[lm-sensors] W83627DHG, steps to use

[Luca Tettamanti]

Il Fri, Dec 29, 2006 at 07:50:54PM -0700, David Hubbard ha scritto: 
> Hi Rudolf,
> 
> It looks like there is some code in the kernel that could be extended
> to provide MSR data for the coretemp driver--maybe you already know
> about this?
> 
> >Btw, using /dev/cpuX/msr device you can read core temperatures, I just
> >copied the algorithm used by the kernel driver. Of course it's not
> >integrated with the rest of the hwmon subsystem...
> >If you're interested I can send you the source file as soon as I get
> >back to home.

I'm talking about an userspace application that read directly msr device
exposed by the kernel driver.
The program itself it's very trivial (I just added a bit of error checking so
it doesn't look so bad ;))

#include <stdio.h>
#include <stdint.h>

#define MSR_IA32_THERM_STATUS 0x019c
#define TJ_MAX 100

int main(void) {
	int cpus = 2;
	int i;
	char msr_name[64];
	FILE *msr;
	uint64_t val;
	int temp;

	for (i = 0; i < cpus; i++) {
		sprintf(msr_name, "/dev/cpu/%d/msr", i);

		msr = fopen(msr_name, "r");
		if (!msr) {
			perror("fopen()");
			return 1;
		}
		fseek(msr, MSR_IA32_THERM_STATUS, SEEK_SET);
		fread(&val, 8, 1, msr);
		fclose(msr);

		/* Valid bit */
		if (!(val & 0x80000000)) {
			fprintf(stderr, "Invalid reading for CPU %d\n", i);
			continue;
		}
		temp = TJ_MAX - ((val >> 16) & 0x7f);

		printf("CPU%d: %d?C\n", i, temp);
	}

	return 0;
}


What Rudolf wants (AFAICS) is a mean to call into the msr module from
the kernel.

Luca
-- 
Recursion n.:
	See Recursion.

[lm-sensors] W83627DHG, steps to use

[Rudolf Marek]

David Hubbard wrote:
> Hi Rudolf,
> 
> It looks like there is some code in the kernel that could be extended
> to provide MSR data for the coretemp driver--maybe you already know
> about this?

My last incarnation of the driver uses the msr.c functions. I wrote to LKML
about this but there was no result. The interface is bit unclean.

Jean,

Any ideas how to proceed with coretemp driver? Maybe best would be just to copy
the routines to the driver and wait until some sane interface to msr appear?

Thanks,

Rudolf

[lm-sensors] W83627DHG, steps to use

[* *]

On 12/27/06, Andrew Gaydenko <a at gaydenko.com> wrote:
> OK, being waiting for answer, I have tried to patch a kernel. Patching
> was OK (except for rejecting in ./Documentation/...). Kernel making gives:
>

You applied one of Rudolph's patches but it was meant to be part of a
set, you missed one of the files.  It's here:
http://lists.lm-sensors.org/pipermail/lm-sensors/2006-October/018128.html

> ...
> Kernel: arch/x86_64/boot/bzImage is ready  (#25)
>   Building modules, stage 2.
>   MODPOST 165 modules
> WARNING: "msr_read" [drivers/hwmon/coretemp.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>
> .config contains this row: CONFIG_X86_MSR=y I have tried to see
> all 'msr_read' occurences, 'grep 'msr_read' -R /usr/src/linux-2.6.19-w-r2/*'
> output is:
>
> Binary file /usr/src/linux-2.6.19-w-r2/arch/x86_64/kernel/msr.o matches
> Binary file /usr/src/linux-2.6.19-w-r2/arch/x86_64/kernel/built-in.o matches
> /usr/src/linux-2.6.19-w-r2/arch/i386/kernel/msr.c:static ssize_t msr_read(struct file *file, char __user * buf,
> /usr/src/linux-2.6.19-w-r2/arch/i386/kernel/msr.c:      .read = msr_read,
> Binary file /usr/src/linux-2.6.19-w-r2/arch/i386/kernel/msr.o matches
> /usr/src/linux-2.6.19-w-r2/drivers/hwmon/coretemp.c:            msr_read(data->id, MSR_IA32_THERM_STATUS, &eax, &edx);
> /usr/src/linux-2.6.19-w-r2/drivers/hwmon/coretemp.c:            err = msr_read(data->id, 0xee, &eax, &edx);
> /usr/src/linux-2.6.19-w-r2/drivers/hwmon/coretemp.c:    err = msr_read(data->id, MSR_IA32_THERM_STATUS, &eax, &edx);
> Binary file /usr/src/linux-2.6.19-w-r2/drivers/hwmon/coretemp.o matches
> /usr/src/linux-2.6.19-w-r2/System.map:ffffffff8026b3d0 t msr_read
> Binary file /usr/src/linux-2.6.19-w-r2/vmlinux matches
>
> Where is my failt?
> gentoo-sources-2.6.19-r2 kernel tree is in use.
>
>
> Andrew
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors at lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
>

[lm-sensors] W83627DHG, steps to use

[Jean Delvare]

Hi Rudolf,

On Tue, 02 Jan 2007 19:49:24 +0100, Rudolf Marek wrote:
> > It looks like there is some code in the kernel that could be extended
> > to provide MSR data for the coretemp driver--maybe you already know
> > about this?
> 
> My last incarnation of the driver uses the msr.c functions. I wrote to LKML
> about this but there was no result. The interface is bit unclean.
> 
> Jean,
> 
> Any ideas how to proceed with coretemp driver? Maybe best would be just to copy
> the routines to the driver and wait until some sane interface to msr appear?

That's a possibility, I admit I just don't know what is best, and I'm a
bit too busy with other stuff to think about it. I have large i2c core
patches on my plate at the moment, and I also need to push a few urgent
patches to Linus using git. Then we have the lm-sensors 2.10.2 release
scheduled. Only after it's done I will have some time to work on
individual drivers.

-- 
Jean Delvare

[lm-sensors] W83627DHG, steps to use

[Jean Delvare]

Hi Andrew, David,

On Fri, 29 Dec 2006 06:24:27 +0300, Andrew Gaydenko wrote:
> Hi, David,
> 
> ==== On Friday 29 December 2006 06:09, you wrote: ===> >Setting pwmX_enable to 0 is supposed to disable the pwm output for
> >that fan, resulting in the maximum fan speed. The w83627ehf and
> >w83627dhg do not have a way to disable the pwm output. Just write 255
> >to pwmX.
> 
> OK, I'm tracing for SVN tree :-)

This is a known bug which was first reported here:
http://lists.lm-sensors.org/pipermail/lm-sensors/2006-November/018291.html
See my answer here:
http://lists.lm-sensors.org/pipermail/lm-sensors/2006-December/018521.html
There's a patch in that post, if you want to try it out, it should solve
the problem. I didn't have the time to try it myself yet. If it works
I'll commit it to lm_sensors SVN before we release 2.10.2.

Thanks,
-- 
Jean Delvare

[lm-sensors] W83627DHG, steps to use

[Andrew Gaydenko]

Aha, applied. Thanks! - it helped. Now these sensors are visible too:

coretemp-isa-0000
Adapter: ISA adapter
temp1:       +36?C  (high =   +85?C)

coretemp-isa-0001
Adapter: ISA adapter
temp1:       +36?C  (high =   +85?C)

And, sorry, additional questions arised. 

- W83627DHG shows CPU temp about 6-8 grad lower (well, and it is single sensor,
  and I don't understand what does single sensors show :-)) rather coretemp sensors.
  Who is more honest? It is important because ASUS P5B-VM seems to not support
  PWM-regulating, so I have soldered PWM-controller and need to be sure CPU
  temp is acceptable,

- KDE's SysGuard see the only coretemp sensor. Is it SysGuard-related bug?


==== On Wednesday 03 January 2007 04:55, you wrote: ===On 12/27/06, Andrew Gaydenko <a at gaydenko.com> wrote:
> OK, being waiting for answer, I have tried to patch a kernel. Patching
> was OK (except for rejecting in ./Documentation/...). Kernel making gives:
>

You applied one of Rudolph's patches but it was meant to be part of a
set, you missed one of the files.  It's here:
http://lists.lm-sensors.org/pipermail/lm-sensors/2006-October/018128.html

[lm-sensors] W83627DHG, steps to use

[richardvoigt at gmail.com]

On 1/3/07, Andrew Gaydenko <a at gaydenko.com> wrote:
> Aha, applied. Thanks! - it helped. Now these sensors are visible too:
>
> coretemp-isa-0000
> Adapter: ISA adapter
> temp1:       +36?C  (high =   +85?C)
>
> coretemp-isa-0001
> Adapter: ISA adapter
> temp1:       +36?C  (high =   +85?C)
>
> And, sorry, additional questions arised.
>
> - W83627DHG shows CPU temp about 6-8 grad lower (well, and it is single sensor,
>   and I don't understand what does single sensors show :-)) rather coretemp sensors.
>   Who is more honest? It is important because ASUS P5B-VM seems to not support
>   PWM-regulating, so I have soldered PWM-controller and need to be sure CPU
>   temp is acceptable,

coretemp is measured at the hottest part of the core, while
motherboard will tend to measure the surface temperature.  A few
degrees difference is expected.  Also that's a really nice temperature
for coretemp, perhaps you have really frigid air conditioning.  My
overclocked Core2Duo (@3.4 GHz) runs coretemps of 51C idle and up to
60C under full load... which is a huge improvement from my old Athlon
MPs which were 56-65C surface temperature.

>
> - KDE's SysGuard see the only coretemp sensor. Is it SysGuard-related bug?
>

I made a patch for KSensors, I don't use SysGuard.

[lm-sensors] W83627DHG, steps to use

[Andrew Gaydenko]

==== On Thursday 04 January 2007 06:34, you wrote: ===...
>coretemp is measured at the hottest part of the core, while
>motherboard will tend to measure the surface temperature.  A few
>degrees difference is expected.  Also that's a really nice temperature
>for coretemp, perhaps you have really frigid air conditioning.  My
>overclocked Core2Duo (@3.4 GHz) runs coretemps of 51C idle and up to
>60C under full load... which is a huge improvement from my old Athlon
>MPs which were 56-65C surface temperature.

[OT]
My aim is a silence rather an overclocking ;-) So I have set Zalaman
9500 to ~1550 rpm (all fans noise are below Samsung HDD noise now).

[T]
OK, I can conclude, coretemp's temps are more "honest", as expected -
closer to cores - closer to truth.


>I made a patch for KSensors, I don't use SysGuard.

It seems like KSensors project is not under development now :-( 
At any case I'll try it with your patch, thanks!