[lm-sensors] sensor details for W83627HG-AW

[lm-sensors] sensor details for W83627HG-AW

[krunal patel]

[-- Attachment #1.1: Type: text/plain, Size: 2336 bytes --]

Hi,

I am trying to run lm-sensor on my machine. It is having W83627HG-AW chip.
I am using linux-2.6.27.45. 
Module loaded are hwmon, hwmon-vid, w83627hf. I am getting error in dmesg as 

w83627hf: Found W83627HF chip at 0x290
hwmon-vid: Unknown VRM version of your x86 CPU

output of cpuinfo:
# cat /proc/cpuinfo 
processor       : 0
vendor_id       : CentaurHauls
cpu family      : 6
model           : 13
model name      : VIA Eden Processor  500MHz
stepping        : 0
cpu MHz         : 499.938
cache size      : 128 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx pni est tm2 xtpr rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en
bogomips        : 999.87
clflush size    : 64
power management:

Senors output :
w83627hf-isa-0290
Adapter: ISA adapter
in0:          +0.69 V  (min =  +0.00 V, max =  +4.08 V)
in1:          +1.06 V  (min =  +0.00 V, max =  +4.08 V)
in2:          +3.30 V  (min =  +2.82 V, max =  +3.79 V)
in3:          +2.99 V  (min =  +3.57 V, max =  +1.73 V)  ALARM
in4:          +3.26 V  (min =  +1.98 V, max =  +4.05 V)
in5:          +3.31 V  (min =  +3.57 V, max =  +3.17 V)  ALARM
in6:          +3.33 V  (min =  +1.78 V, max =  +0.53 V)  ALARM
in7:          +3.28 V  (min =  +0.26 V, max =  +2.29 V)  ALARM
in8:          +3.50 V  (min =  +2.99 V, max =  +0.64 V)  ALARM
fan1:           0 RPM  (min = 14062 RPM, div = 2)  ALARM
fan2:           0 RPM  (min =   -1 RPM, div = 2)  ALARM
fan3:           0 RPM  (min =   -1 RPM, div = 2)  ALARM
temp1:        +55.0 C  (high =  +9.0 C, hyst = +32.0 C)  ALARM  sensor = thermistor
temp2:        +39.5 C  (high = +120.0 C, hyst = +115.0 C)  sensor = diode
temp3:        -48.0 C  (high = +120.0 C, hyst = +115.0 C)  sensor = thermistor
cpu0_vid:    +0.000 V
beep_enable: enabled

Values different then What i get in BIOS.
Bios system health:
System Temp : 52C / 125 F
CPU Temp : 43C/ 109F
FAN1 : 0
FAN2 : 0
FAN3 : 0
Vcore : 0.68V
Vccp : 1.05V
+3.3V : 3.29V
+5V : 5.05V
+12V : 12.40V
VBAT : 3.50V
5VSB : 4.99V




	
	
	
	
	
		

Regards,
Krunal

[-- Attachment #1.2: Type: text/html, Size: 4450 bytes --]

[-- 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] sensor details for W83627HG-AW

[Jean Delvare]

Hi Krunal,

On Fri, 3 Jun 2011 11:31:32 +0530 (IST), krunal patel wrote:
> I am trying to run lm-sensor on my machine. It is having W83627HG-AW chip.
> I am using linux-2.6.27.45. 
> Module loaded are hwmon, hwmon-vid, w83627hf. I am getting error in dmesg as 
> 
> w83627hf: Found W83627HF chip at 0x290
> hwmon-vid: Unknown VRM version of your x86 CPU

Indeed we don't know yet the VID conversion table for this CPU
family/model. I looked at the VIA website but couldn't find a public
datasheet for it.

> output of cpuinfo:
> # cat /proc/cpuinfo 
> processor       : 0
> vendor_id       : CentaurHauls
> cpu family      : 6
> model           : 13
> model name      : VIA Eden Processor  500MHz
> stepping        : 0
> cpu MHz         : 499.938
> cache size      : 128 KB
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 1
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx pni est tm2 xtpr rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en
> bogomips        : 999.87
> clflush size    : 64
> power management:

Brilly, Kary, can you help us here, please? Where can we get the VID pin
codes -> Vcore voltage conversion table for VIA CPU family 6, model 13?
This is needed to update drivers/hwmon/hwmon-vid.c.

Thanks,
-- 
Jean Delvare

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

Re: [lm-sensors] sensor details for W83627HG-AW

[BrillyWu]

Hi Jean,
Since the information shows that it's a C7 series CPU, the link http://gmb.viatech.com.cn/resource/downloads/Datasheet/CPU/VIA+C7-M+datasheet+2.5.pdf should have the information you need 

Brilly

-----Original Message-----
From: Jean Delvare [mailto:khali@linux-fr.org] 
Sent: Saturday, June 04, 2011 7:08 PM
To: krunal patel; Brilly Wu
Cc: lm-sensors@lm-sensors.org; Kary Jin
Subject: Re: [lm-sensors] sensor details for W83627HG-AW

Hi Krunal,

On Fri, 3 Jun 2011 11:31:32 +0530 (IST), krunal patel wrote:
> I am trying to run lm-sensor on my machine. It is having W83627HG-AW chip.
> I am using linux-2.6.27.45. 
> Module loaded are hwmon, hwmon-vid, w83627hf. I am getting error in 
> dmesg as
> 
> w83627hf: Found W83627HF chip at 0x290
> hwmon-vid: Unknown VRM version of your x86 CPU

Indeed we don't know yet the VID conversion table for this CPU family/model. I looked at the VIA website but couldn't find a public datasheet for it.

> output of cpuinfo:
> # cat /proc/cpuinfo
> processor       : 0
> vendor_id       : CentaurHauls
> cpu family      : 6
> model           : 13
> model name      : VIA Eden Processor  500MHz stepping        : 0 cpu 
> MHz         : 499.938 cache size      : 128 KB fdiv_bug        : no 
> hlt_bug         : no f00f_bug        : no coma_bug        : no fpu             
> : yes fpu_exception   : yes cpuid level     : 1 wp              : yes 
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
> cmov pat clflush acpi mmx fxsr sse sse2 tm nx pni est tm2 xtpr rng 
> rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en bogomips        : 
> 999.87 clflush size    : 64 power management:

Brilly, Kary, can you help us here, please? Where can we get the VID pin codes -> Vcore voltage conversion table for VIA CPU family 6, model 13?
This is needed to update drivers/hwmon/hwmon-vid.c.

Thanks,
--
Jean Delvare

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

Re: [lm-sensors] sensor details for W83627HG-AW

[Jean Delvare]

Hi Brilly,

Thanks for the quick reply, this is exactly what I needed. Is there a
way I could have found the document myself?

There are still 2 issues left though:

1* The datasheet doesn't seem to cover the model Krunal is running (VIA
   Eden at 500 MHz). The lowest frequency in the datasheet is 1.0 GHz.

2* The datasheet mentions 2 different VID tables, a 6-bit one for
   nanoBGA2 packages and a 7-bit one for mobileBGA packages. They are
   not compatible. How can I differentiate between nanoBGA2 packages
   and mobileBGA packages, so that I can pick the right VID table?

Thanks,
Jean

On Wed, 8 Jun 2011 14:32:14 +0800, BrillyWu@viatech.com.cn wrote:
> Hi Jean,
> Since the information shows that it's a C7 series CPU, the link http://gmb.viatech.com.cn/resource/downloads/Datasheet/CPU/VIA+C7-M+datasheet+2.5.pdf should have the information you need 
> 
> Brilly
> 
> -----Original Message-----
> From: Jean Delvare [mailto:khali@linux-fr.org] 
> Sent: Saturday, June 04, 2011 7:08 PM
> To: krunal patel; Brilly Wu
> Cc: lm-sensors@lm-sensors.org; Kary Jin
> Subject: Re: [lm-sensors] sensor details for W83627HG-AW
> 
> Hi Krunal,
> 
> On Fri, 3 Jun 2011 11:31:32 +0530 (IST), krunal patel wrote:
> > I am trying to run lm-sensor on my machine. It is having W83627HG-AW chip.
> > I am using linux-2.6.27.45. 
> > Module loaded are hwmon, hwmon-vid, w83627hf. I am getting error in 
> > dmesg as
> > 
> > w83627hf: Found W83627HF chip at 0x290
> > hwmon-vid: Unknown VRM version of your x86 CPU
> 
> Indeed we don't know yet the VID conversion table for this CPU family/model. I looked at the VIA website but couldn't find a public datasheet for it.
> 
> > output of cpuinfo:
> > # cat /proc/cpuinfo
> > processor       : 0
> > vendor_id       : CentaurHauls
> > cpu family      : 6
> > model           : 13
> > model name      : VIA Eden Processor  500MHz stepping        : 0 cpu 
> > MHz         : 499.938 cache size      : 128 KB fdiv_bug        : no 
> > hlt_bug         : no f00f_bug        : no coma_bug        : no fpu             
> > : yes fpu_exception   : yes cpuid level     : 1 wp              : yes 
> > flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
> > cmov pat clflush acpi mmx fxsr sse sse2 tm nx pni est tm2 xtpr rng 
> > rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en bogomips        : 
> > 999.87 clflush size    : 64 power management:
> 
> Brilly, Kary, can you help us here, please? Where can we get the VID pin codes -> Vcore voltage conversion table for VIA CPU family 6, model 13?
> This is needed to update drivers/hwmon/hwmon-vid.c.
> 
> Thanks,
> --
> Jean Delvare

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

Re: [lm-sensors] sensor details for W83627HG-AW

[BrillyWu]

Hi Jean,
I'm sorry. Because I am in charge of PadLock engine software development and information security technology, so I can't answer these question. I think you can inquire the question through VIA website's Request Form, thank you.

This web site may help you:

http://www.via.com.tw/en/support/

Brilly



-----Original Message-----
From: Jean Delvare [mailto:khali@linux-fr.org] 
Sent: Wednesday, June 08, 2011 3:46 PM
To: Brilly Wu
Cc: krunal_smiles@yahoo.com; lm-sensors@lm-sensors.org; Kary Jin
Subject: Re: [lm-sensors] sensor details for W83627HG-AW

Hi Brilly,

Thanks for the quick reply, this is exactly what I needed. Is there a way I could have found the document myself?

There are still 2 issues left though:

1* The datasheet doesn't seem to cover the model Krunal is running (VIA
   Eden at 500 MHz). The lowest frequency in the datasheet is 1.0 GHz.

2* The datasheet mentions 2 different VID tables, a 6-bit one for
   nanoBGA2 packages and a 7-bit one for mobileBGA packages. They are
   not compatible. How can I differentiate between nanoBGA2 packages
   and mobileBGA packages, so that I can pick the right VID table?

Thanks,
Jean

On Wed, 8 Jun 2011 14:32:14 +0800, BrillyWu@viatech.com.cn wrote:
> Hi Jean,
> Since the information shows that it's a C7 series CPU, the link 
> http://gmb.viatech.com.cn/resource/downloads/Datasheet/CPU/VIA+C7-M+da
> tasheet+2.5.pdf should have the information you need
> 
> Brilly
> 
> -----Original Message-----
> From: Jean Delvare [mailto:khali@linux-fr.org]
> Sent: Saturday, June 04, 2011 7:08 PM
> To: krunal patel; Brilly Wu
> Cc: lm-sensors@lm-sensors.org; Kary Jin
> Subject: Re: [lm-sensors] sensor details for W83627HG-AW
> 
> Hi Krunal,
> 
> On Fri, 3 Jun 2011 11:31:32 +0530 (IST), krunal patel wrote:
> > I am trying to run lm-sensor on my machine. It is having W83627HG-AW chip.
> > I am using linux-2.6.27.45. 
> > Module loaded are hwmon, hwmon-vid, w83627hf. I am getting error in 
> > dmesg as
> > 
> > w83627hf: Found W83627HF chip at 0x290
> > hwmon-vid: Unknown VRM version of your x86 CPU
> 
> Indeed we don't know yet the VID conversion table for this CPU family/model. I looked at the VIA website but couldn't find a public datasheet for it.
> 
> > output of cpuinfo:
> > # cat /proc/cpuinfo
> > processor       : 0
> > vendor_id       : CentaurHauls
> > cpu family      : 6
> > model           : 13
> > model name      : VIA Eden Processor  500MHz stepping        : 0 cpu 
> > MHz         : 499.938 cache size      : 128 KB fdiv_bug        : no 
> > hlt_bug         : no f00f_bug        : no coma_bug        : no fpu
> > : yes fpu_exception   : yes cpuid level     : 1 wp              : 
> > yes flags           : fpu vme de pse tsc msr pae mce cx8 apic sep 
> > mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx pni est tm2 
> > xtpr rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en bogomips        :
> > 999.87 clflush size    : 64 power management:
> 
> Brilly, Kary, can you help us here, please? Where can we get the VID pin codes -> Vcore voltage conversion table for VIA CPU family 6, model 13?
> This is needed to update drivers/hwmon/hwmon-vid.c.
> 
> Thanks,
> --
> Jean Delvare

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

Re: [lm-sensors] sensor details for W83627HG-AW

[Jean Delvare]

On Thu, 9 Jun 2011 10:41:42 +0800, BrillyWu@viatech.com.cn wrote:
> Hi Jean,
> I'm sorry. Because I am in charge of PadLock engine software development and information security technology, so I can't answer these question.

I know that. To be honest, I was hoping that Kary Jin would step in...

> I think you can inquire the question through VIA website's Request Form, thank you.
> 
> This web site may help you:
> 
> http://www.via.com.tw/en/support/

I've just done that, thanks for the suggestion!

-- 
Jean Delvare

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

Re: [lm-sensors] sensor details for W83627HG-AW

[Jean Delvare]

Hi Krunal,

On Sat, 4 Jun 2011 13:08:18 +0200, Jean Delvare wrote:
> Brilly, Kary, can you help us here, please? Where can we get the VID pin
> codes -> Vcore voltage conversion table for VIA CPU family 6, model 13?
> This is needed to update drivers/hwmon/hwmon-vid.c.

I received information from VIA and was able to update hwmon-vid to
support your CPU. Patch below. I couldn't test it as I don't have the
hardware. I've also made the modified hwmon-vid driver available as a
standalone driver at:
  http://khali.linux-fr.org/devel/misc/hwmon-vid/
with instructions at:
  http://khali.linux-fr.org/devel/misc/INSTALL

Please test if you can, and report.


From: Jean Delvare <khali@linux-fr.org>
Subject: hwmon-vid: Add support for VIA C7-D

The VIA C7-D CPU (Eden 90 nm) can use two different VID tables, we
have to check the value of a MSR to decide which one to use.

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

--- linux-3.0-rc3.orig/drivers/hwmon/hwmon-vid.c	2011-06-20 13:43:24.000000000 +0200
+++ linux-3.0-rc3/drivers/hwmon/hwmon-vid.c	2011-06-20 17:58:18.000000000 +0200
@@ -206,10 +206,30 @@ static struct vrm_model vrm_models[] = {
 	{X86_VENDOR_CENTAUR, 0x6, 0x9, ANY, 17},	/* C3-M, Eden-N */
 	{X86_VENDOR_CENTAUR, 0x6, 0xA, 0x7, 0},		/* No information */
 	{X86_VENDOR_CENTAUR, 0x6, 0xA, ANY, 13},	/* C7, Esther */
+	{X86_VENDOR_CENTAUR, 0x6, 0xD, ANY, 134},	/* C7-D, Eden (90 nm) */
 
 	{X86_VENDOR_UNKNOWN, ANY, ANY, ANY, 0}		/* stop here */
 };
 
+/*
+ * Special case for VIA C7-D: there are two different possible
+ * VID tables, so we have to figure out first, which one must
+ * be used.
+ */
+static u8 get_via_c7d_vrm(void)
+{
+	unsigned int eax, edx;
+
+	rdmsr(0x198, eax, edx);
+	if ((edx & 0xff) > 0x3f) {
+		pr_info("Using %d-bit VID table for VIA C7-D CPU\n", 7);
+		return 14;
+	} else {
+		pr_info("Using %d-bit VID table for VIA C7-D CPU\n", 6);
+		return 13;
+	}
+}
+
 static u8 find_vrm(u8 eff_family, u8 eff_model, u8 eff_stepping, u8 vendor)
 {
 	int i = 0;
@@ -249,6 +269,9 @@ u8 vid_which_vrm(void)
 	vrm_ret = find_vrm(eff_family, eff_model, eff_stepping, c->x86_vendor);
 	if (vrm_ret = 0)
 		pr_info("Unknown VRM version of your x86 CPU\n");
+	if (vrm_ret = 134)
+		vrm_ret = get_via_c7d_vrm();
+
 	return vrm_ret;
 }
 


-- 
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] sensor details for W83627HG-AW

[krunal patel]

[-- Attachment #1.1: Type: text/plain, Size: 4685 bytes --]

Hi Jean,
Its working now. Thank you very much for your patch.
dmesg output--------------------w83627hf: Found W83627HF chip at 0x290Using 6-bit VID table for VIA C7-D CPU

# sensors --------------w83627hf-isa-0290Adapter: ISA adapterin0:          +0.69 V  (min =  +0.00 V, max =  +4.08 V)in1:          +1.06 V  (min =  +0.00 V, max =  +4.08 V)in2:          +3.30 V  (min =  +2.82 V, max =  +3.79 V)in3:          +2.99 V  (min =  +3.57 V, max =  +1.98 V)  ALARMin4:          +3.28 V  (min =  +1.98 V, max =  +4.05 V)in5:          +3.30 V  (min =  +3.57 V, max =  +3.30 V)  ALARMin6:          +3.33 V  (min =  +1.78 V, max =  +0.53 V)  ALARMin7:          +3.30 V  (min =  +0.77 V, max =  +2.29 V)  ALARMin8:          +3.52 V  (min =  +3.06 V, max =  +0.64 V)  ALARMfan1:           0 RPM  (min = 13775 RPM, div = 2)  ALARMfan2:           0 RPM  (min =   -1 RPM, div = 2)  ALARMfan3:           0 RPM  (min = 3515 RPM, div = 2)  ALARMtemp1:        +52.0 C  (high =  +9.0 C, hyst = +32.0 C)  ALARM  sensor = thermistortemp2:      
  +38.5 C  (high = +120.0 C, hyst = +115.0 C)  sensor = diodetemp3:        -48.0 C  (high = +120.0 C, hyst = +115.0 C)  sensor = thermistorcpu0_vid:    +1.212 Vbeep_enable: enabled


I looked into driver code and hwmon related code. All sensor data is exported to user space using sysfs.
One thing I understood is there is no interrupt mechanism in sensor chip so we need to read data from chip's memory. So for periodic data we need to do polling at userspace (like sensord). 
Can I implement timer in driver and do polling in Kernel? 
What I want to do is get userspace event only when Alarm is raised. If I implement timer and netlink communication in driver will it be correct way to do it? As I do not find any other way.
Best Regards,Krunal Patel

--- On Mon, 20/6/11, Jean Delvare <khali@linux-fr.org> wrote:

From: Jean Delvare <khali@linux-fr.org>
Subject: Re: [lm-sensors] sensor details for W83627HG-AW
To: "krunal patel" <krunal_smiles@yahoo.com>
Cc: lm-sensors@lm-sensors.org
Date: Monday, 20 June, 2011, 11:30 PM

Hi Krunal,

On Sat, 4 Jun 2011 13:08:18 +0200, Jean Delvare wrote:
> Brilly, Kary, can you help us here, please? Where can we get the VID pin
> codes -> Vcore voltage conversion table for VIA CPU family 6, model 13?
> This is needed to update drivers/hwmon/hwmon-vid.c.

I received information from VIA and was able to update hwmon-vid to
support your CPU. Patch below. I couldn't test it as I don't have the
hardware. I've also made the modified hwmon-vid driver available as a
standalone driver at:
  http://khali.linux-fr.org/devel/misc/hwmon-vid/
with instructions at:
  http://khali.linux-fr.org/devel/misc/INSTALL

Please test if you can, and report.


From: Jean Delvare <khali@linux-fr.org>
Subject: hwmon-vid: Add support for VIA C7-D

The VIA C7-D CPU (Eden 90 nm) can use two different VID tables, we
have to check the value of a MSR to decide which one to use.

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

--- linux-3.0-rc3.orig/drivers/hwmon/hwmon-vid.c    2011-06-20 13:43:24.000000000 +0200
+++ linux-3.0-rc3/drivers/hwmon/hwmon-vid.c    2011-06-20 17:58:18.000000000 +0200
@@ -206,10 +206,30 @@ static struct vrm_model vrm_models[] = {
     {X86_VENDOR_CENTAUR, 0x6, 0x9, ANY, 17},    /* C3-M, Eden-N */
     {X86_VENDOR_CENTAUR, 0x6, 0xA, 0x7, 0},        /* No information */
     {X86_VENDOR_CENTAUR, 0x6, 0xA, ANY, 13},    /* C7, Esther */
+    {X86_VENDOR_CENTAUR, 0x6, 0xD, ANY, 134},    /* C7-D, Eden (90 nm) */
 
     {X86_VENDOR_UNKNOWN, ANY, ANY, ANY, 0}        /* stop here */
 };
 
+/*
+ * Special case for VIA C7-D: there are two different possible
+ * VID tables, so we have to figure out first, which one must
+ * be used.
+ */
+static u8 get_via_c7d_vrm(void)
+{
+    unsigned int eax, edx;
+
+    rdmsr(0x198, eax, edx);
+    if ((edx & 0xff) > 0x3f) {
+        pr_info("Using %d-bit VID table for VIA C7-D CPU\n", 7);
+        return 14;
+    } else {
+        pr_info("Using %d-bit VID table for VIA C7-D CPU\n", 6);
+        return 13;
+    }
+}
+
 static u8 find_vrm(u8 eff_family, u8 eff_model, u8 eff_stepping, u8 vendor)
 {
     int i = 0;
@@ -249,6 +269,9 @@ u8 vid_which_vrm(void)
     vrm_ret = find_vrm(eff_family, eff_model, eff_stepping, c->x86_vendor);
     if (vrm_ret == 0)
         pr_info("Unknown VRM version of your x86 CPU\n");
+    if (vrm_ret == 134)
+        vrm_ret = get_via_c7d_vrm();
+
     return vrm_ret;
 }
 


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

[-- Attachment #1.2: Type: text/html, Size: 7409 bytes --]

[-- 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] sensor details for W83627HG-AW

[Jean Delvare]

On Tue, 21 Jun 2011 12:40:49 +0530 (IST), krunal patel wrote:
> Hi Jean,
> Its working now. Thank you very much for your patch.
> dmesg output--------------------
> w83627hf: Found W83627HF chip at 0x290
> Using 6-bit VID table for VIA C7-D CPU
> 
> # sensors --------------
> w83627hf-isa-0290
> Adapter: ISA adapter
> in0:          +0.69 V  (min =  +0.00 V, max =  +4.08 V)
> in1:          +1.06 V  (min =  +0.00 V, max =  +4.08 V)
> in2:          +3.30 V  (min =  +2.82 V, max =  +3.79 V)
> in3:          +2.99 V  (min =  +3.57 V, max =  +1.98 V)  ALARM
> in4:          +3.28 V  (min =  +1.98 V, max =  +4.05 V)
> in5:          +3.30 V  (min =  +3.57 V, max =  +3.30 V)  ALARM
> in6:          +3.33 V  (min =  +1.78 V, max =  +0.53 V)  ALARM
> in7:          +3.30 V  (min =  +0.77 V, max =  +2.29 V)  ALARM
> in8:          +3.52 V  (min =  +3.06 V, max =  +0.64 V)  ALARM
> fan1:           0 RPM  (min = 13775 RPM, div = 2)  ALARM
> fan2:           0 RPM  (min =   -1 RPM, div = 2)  ALARM
> fan3:           0 RPM  (min = 3515 RPM, div = 2)  ALARM
> temp1:        +52.0 C  (high =  +9.0 C, hyst = +32.0 C)  ALARM  sensor = thermistor
> temp2:        +38.5 C  (high = +120.0 C, hyst = +115.0 C)  sensor = diode
> temp3:        -48.0 C  (high = +120.0 C, hyst = +115.0 C)  sensor = thermistor
> cpu0_vid:    +1.212 V
> beep_enable: enabled

According to the documentation I have, your CPU should be running at
0.684 V (assuming it is a ULV variant), so in0 is Vcore. It does not
match cpu0_vid, but the other possible VID decoding table wouldn't
either. So I think that the VID pins are simply not properly routed to
your monitoring chip.

Ah, stupid me. Of course they aren't. The W83627HF only has 5 VID pins,
so you can't route a 6-bit VID value to it...

So basically this means that you can ignore the cpu0_vid value reported
by the w83627hf driver, it's bogus. Ideally the drivers would notice
the mismatch and wouldn't expose a VID value which can't be correct. I
don't have the time to fix it now so I've created a support ticket for
later:
  http://www.lm-sensors.org/ticket/2383

Could you please install the msr-tools package, load the msr driver,
and run as root:
# rdmsr -x 0x198
and report the result.

BTW you should also be able to use the via-cputemp driver. Didn't
sensors-detect suggest that?

> I looked into driver code and hwmon related code. All sensor data is exported to user space using sysfs.
> One thing I understood is there is no interrupt mechanism in sensor chip so we need to read data from chip's memory. So for periodic data we need to do polling at userspace (like sensord).

Yes, this is correct, except that _some_ devices actually support
interrupts. But libsensors currently doesn't support that, and most
drivers don't implement it anyway.

> Can I implement timer in driver and do polling in Kernel?

Technically you certainly can, but I very much doubt that such code
would be accepted in the kernel. If polling is necessary, then it is
better done in user-space than in the kernel, because user-space can
choose the polling set and period depending on the exact needs.

If you think that in-kernel polling has an advantage, please argue.

> What I want to do is get userspace event only when Alarm is raised. If I implement timer and netlink communication in driver will it be correct way to do it? As I do not find any other way.

I am no expert in this area, but I see no reason to go with netlink, it
seems to me that poll/select on the relevant alarm files themselves
should work. Guenter, I think you discussed this some times ago?

Krunal, please also search for "poll notification" in
Documentation/hwmon/sysfs-interface. This suggests that a subset of the
attributes implement poll support already. I didn't look into this and
won't have time to do so, sorry.

But again this only applies to devices which raise interrupts on alarm,
so that no in-kernel polling is needed.

-- 
Jean Delvare

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

Re: [lm-sensors] sensor details for W83627HG-AW

[Guenter Roeck]

On Tue, Jun 21, 2011 at 07:50:50AM -0400, Jean Delvare wrote:
> On Tue, 21 Jun 2011 12:40:49 +0530 (IST), krunal patel wrote:
> > Hi Jean,
> > Its working now. Thank you very much for your patch.
> > dmesg output--------------------
> > w83627hf: Found W83627HF chip at 0x290
> > Using 6-bit VID table for VIA C7-D CPU
> > 
> > # sensors --------------
> > w83627hf-isa-0290
> > Adapter: ISA adapter
> > in0:          +0.69 V  (min =  +0.00 V, max =  +4.08 V)
> > in1:          +1.06 V  (min =  +0.00 V, max =  +4.08 V)
> > in2:          +3.30 V  (min =  +2.82 V, max =  +3.79 V)
> > in3:          +2.99 V  (min =  +3.57 V, max =  +1.98 V)  ALARM
> > in4:          +3.28 V  (min =  +1.98 V, max =  +4.05 V)
> > in5:          +3.30 V  (min =  +3.57 V, max =  +3.30 V)  ALARM
> > in6:          +3.33 V  (min =  +1.78 V, max =  +0.53 V)  ALARM
> > in7:          +3.30 V  (min =  +0.77 V, max =  +2.29 V)  ALARM
> > in8:          +3.52 V  (min =  +3.06 V, max =  +0.64 V)  ALARM
> > fan1:           0 RPM  (min = 13775 RPM, div = 2)  ALARM
> > fan2:           0 RPM  (min =   -1 RPM, div = 2)  ALARM
> > fan3:           0 RPM  (min = 3515 RPM, div = 2)  ALARM
> > temp1:        +52.0 C  (high =  +9.0 C, hyst = +32.0 C)  ALARM  sensor = thermistor
> > temp2:        +38.5 C  (high = +120.0 C, hyst = +115.0 C)  sensor = diode
> > temp3:        -48.0 C  (high = +120.0 C, hyst = +115.0 C)  sensor = thermistor
> > cpu0_vid:    +1.212 V
> > beep_enable: enabled
> 
> According to the documentation I have, your CPU should be running at
> 0.684 V (assuming it is a ULV variant), so in0 is Vcore. It does not
> match cpu0_vid, but the other possible VID decoding table wouldn't
> either. So I think that the VID pins are simply not properly routed to
> your monitoring chip.
> 
> Ah, stupid me. Of course they aren't. The W83627HF only has 5 VID pins,
> so you can't route a 6-bit VID value to it...
> 
> So basically this means that you can ignore the cpu0_vid value reported
> by the w83627hf driver, it's bogus. Ideally the drivers would notice
> the mismatch and wouldn't expose a VID value which can't be correct. I
> don't have the time to fix it now so I've created a support ticket for
> later:
>   http://www.lm-sensors.org/ticket/2383
> 
> Could you please install the msr-tools package, load the msr driver,
> and run as root:
> # rdmsr -x 0x198
> and report the result.
> 
> BTW you should also be able to use the via-cputemp driver. Didn't
> sensors-detect suggest that?
> 
> > I looked into driver code and hwmon related code. All sensor data is exported to user space using sysfs.
> > One thing I understood is there is no interrupt mechanism in sensor chip so we need to read data from chip's memory. So for periodic data we need to do polling at userspace (like sensord).
> 
> Yes, this is correct, except that _some_ devices actually support
> interrupts. But libsensors currently doesn't support that, and most
> drivers don't implement it anyway.
> 
> > Can I implement timer in driver and do polling in Kernel?
> 
> Technically you certainly can, but I very much doubt that such code
> would be accepted in the kernel. If polling is necessary, then it is
> better done in user-space than in the kernel, because user-space can
> choose the polling set and period depending on the exact needs.
> 
> If you think that in-kernel polling has an advantage, please argue.
> 
> > What I want to do is get userspace event only when Alarm is raised. If I implement timer and netlink communication in driver will it be correct way to do it? As I do not find any other way.
> 
> I am no expert in this area, but I see no reason to go with netlink, it
> seems to me that poll/select on the relevant alarm files themselves
> should work. Guenter, I think you discussed this some times ago?
> 
Yes it does, assuming the driver performs some activity on those files,
ie supports interrupts which trigger a file event. It is on my plate to update
some of the hwmon drivers to support it, but I did not yet have the time
to do it.
 
> Krunal, please also search for "poll notification" in
> Documentation/hwmon/sysfs-interface. This suggests that a subset of the
> attributes implement poll support already. I didn't look into this and
> won't have time to do so, sorry.
> 
> But again this only applies to devices which raise interrupts on alarm,
> so that no in-kernel polling is needed.
> 
Exactly.

Thanks,
Guenter

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

Re: [lm-sensors] sensor details for W83627HG-AW

[krunal patel]

Jean,

Thank you very much for your support and explanation. Please find my comments in line.

Best Regards,
Krunal Patel


--- On Tue, 21/6/11, Jean Delvare <khali@linux-fr.org> wrote:

> From: Jean Delvare <khali@linux-fr.org>
> Subject: Re: [lm-sensors] sensor details for W83627HG-AW
> To: "krunal patel" <krunal_smiles@yahoo.com>
> Cc: lm-sensors@lm-sensors.org, "Guenter Roeck" <guenter.roeck@ericsson.com>
> Date: Tuesday, 21 June, 2011, 5:20 PM
> On Tue, 21 Jun 2011 12:40:49 +0530
> (IST), krunal patel wrote:
> > Hi Jean,
> > Its working now. Thank you very much for your patch.
> > dmesg output--------------------
> > w83627hf: Found W83627HF chip at 0x290
> > Using 6-bit VID table for VIA C7-D CPU
> > 
> > # sensors --------------
> > w83627hf-isa-0290
> > Adapter: ISA adapter
> > in0:          +0.69 V  (min =  +0.00 V, max >  +4.08 V)
> > in1:          +1.06 V  (min =  +0.00 V, max >  +4.08 V)
> > in2:          +3.30 V  (min =  +2.82 V, max >  +3.79 V)
> > in3:          +2.99 V  (min =  +3.57 V, max >  +1.98 V)  ALARM
> > in4:          +3.28 V  (min =  +1.98 V, max >  +4.05 V)
> > in5:          +3.30 V  (min =  +3.57 V, max >  +3.30 V)  ALARM
> > in6:          +3.33 V  (min =  +1.78 V, max >  +0.53 V)  ALARM
> > in7:          +3.30 V  (min =  +0.77 V, max >  +2.29 V)  ALARM
> > in8:          +3.52 V  (min =  +3.06 V, max >  +0.64 V)  ALARM
> > fan1:           0 RPM  (min = 13775 RPM, div > 2)  ALARM
> > fan2:           0 RPM  (min =   -1 RPM, div > 2)  ALARM
> > fan3:           0 RPM  (min = 3515 RPM, div = 2)
>  ALARM
> > temp1:        +52.0 C  (high =  +9.0 C, hyst > +32.0 C)  ALARM  sensor = thermistor
> > temp2:        +38.5 C  (high = +120.0 C, hyst > +115.0 C)  sensor = diode
> > temp3:        -48.0 C  (high = +120.0 C, hyst > +115.0 C)  sensor = thermistor
> > cpu0_vid:    +1.212 V
> > beep_enable: enabled
> 
> According to the documentation I have, your CPU should be
> running at
> 0.684 V (assuming it is a ULV variant), so in0 is Vcore. It
> does not
> match cpu0_vid, but the other possible VID decoding table
> wouldn't
> either. So I think that the VID pins are simply not
> properly routed to
> your monitoring chip.
> 
> Ah, stupid me. Of course they aren't. The W83627HF only has
> 5 VID pins,
> so you can't route a 6-bit VID value to it...
> 
> So basically this means that you can ignore the cpu0_vid
> value reported
> by the w83627hf driver, it's bogus. Ideally the drivers
> would notice
> the mismatch and wouldn't expose a VID value which can't be
> correct. I
> don't have the time to fix it now so I've created a support
> ticket for
> later:
>   http://www.lm-sensors.org/ticket/2383
> 
> Could you please install the msr-tools package, load the
> msr driver,
> and run as root:
> # rdmsr -x 0x198
> and report the result.
> 
Following is output you asked for
# rdmsr -x 0x198        
400050004000500

> BTW you should also be able to use the via-cputemp driver.
> Didn't
> sensors-detect suggest that?
> 
I didn't used sensors-detect because it was wasting my time in resolving perl issues in my system. So I opened case, located chip and loaded related module.
> > I looked into driver code and hwmon related code. All
> sensor data is exported to user space using sysfs.
> > One thing I understood is there is no interrupt
> mechanism in sensor chip so we need to read data from chip's
> memory. So for periodic data we need to do polling at
> userspace (like sensord).
> 
> Yes, this is correct, except that _some_ devices actually
> support
> interrupts. But libsensors currently doesn't support that,
> and most
> drivers don't implement it anyway.
> 
> > Can I implement timer in driver and do polling in
> Kernel?
> 
> Technically you certainly can, but I very much doubt that
> such code
> would be accepted in the kernel. If polling is necessary,
> then it is
> better done in user-space than in the kernel, because
> user-space can
> choose the polling set and period depending on the exact
> needs.
> 
> If you think that in-kernel polling has an advantage,
> please argue.
> 
I thought kernel timer is lighter then application in userspace. 
> > What I want to do is get userspace event only when
> Alarm is raised. If I implement timer and netlink
> communication in driver will it be correct way to do it? As
> I do not find any other way.
> 
> I am no expert in this area, but I see no reason to go with
> netlink, it
> seems to me that poll/select on the relevant alarm files
> themselves
> should work. Guenter, I think you discussed this some times
> ago?
> 
> Krunal, please also search for "poll notification" in
> Documentation/hwmon/sysfs-interface. This suggests that a
> subset of the
> attributes implement poll support already. I didn't look
> into this and
> won't have time to do so, sorry.
> 
I am not find related info in linux-2.6.27.45, I will look in latest version.
> But again this only applies to devices which raise
> interrupts on alarm,
> so that no in-kernel polling is needed.
> 
> -- 
> Jean Delvare
> 



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

Re: [lm-sensors] sensor details for W83627HG-AW

[krunal patel]

Hi Guenter,

What I understood is, driver must implement interrupt handler (if chip supports) which will update sysfs files which are read from userspace using select.

Can you give me sample code regarding this. I will try at my end.

Best Regards,
Krunal Patel


--- On Tue, 21/6/11, Guenter Roeck <guenter.roeck@ericsson.com> wrote:

> From: Guenter Roeck <guenter.roeck@ericsson.com>
> Subject: Re: [lm-sensors] sensor details for W83627HG-AW
> To: "Jean Delvare" <khali@linux-fr.org>
> Cc: "krunal patel" <krunal_smiles@yahoo.com>, "lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>
> Date: Tuesday, 21 June, 2011, 5:29 PM
> On Tue, Jun 21, 2011 at 07:50:50AM
> -0400, Jean Delvare wrote:
> > On Tue, 21 Jun 2011 12:40:49 +0530 (IST), krunal patel
> wrote:
> > > Hi Jean,
> > > Its working now. Thank you very much for your
> patch.
> > > dmesg output--------------------
> > > w83627hf: Found W83627HF chip at 0x290
> > > Using 6-bit VID table for VIA C7-D CPU
> > > 
> > > # sensors --------------
> > > w83627hf-isa-0290
> > > Adapter: ISA adapter
> > > in0:          +0.69 V  (min =  +0.00 V,
> max =  +4.08 V)
> > > in1:          +1.06 V  (min =  +0.00 V,
> max =  +4.08 V)
> > > in2:          +3.30 V  (min =  +2.82 V,
> max =  +3.79 V)
> > > in3:          +2.99 V  (min =  +3.57 V,
> max =  +1.98 V)  ALARM
> > > in4:          +3.28 V  (min =  +1.98 V,
> max =  +4.05 V)
> > > in5:          +3.30 V  (min =  +3.57 V,
> max =  +3.30 V)  ALARM
> > > in6:          +3.33 V  (min =  +1.78 V,
> max =  +0.53 V)  ALARM
> > > in7:          +3.30 V  (min =  +0.77 V,
> max =  +2.29 V)  ALARM
> > > in8:          +3.52 V  (min =  +3.06 V,
> max =  +0.64 V)  ALARM
> > > fan1:           0 RPM  (min = 13775 RPM,
> div = 2)  ALARM
> > > fan2:           0 RPM  (min =   -1 RPM,
> div = 2)  ALARM
> > > fan3:           0 RPM  (min = 3515 RPM, div
> = 2)  ALARM
> > > temp1:        +52.0 C  (high =  +9.0 C,
> hyst = +32.0 C)  ALARM  sensor = thermistor
> > > temp2:        +38.5 C  (high = +120.0 C,
> hyst = +115.0 C)  sensor = diode
> > > temp3:        -48.0 C  (high = +120.0 C,
> hyst = +115.0 C)  sensor = thermistor
> > > cpu0_vid:    +1.212 V
> > > beep_enable: enabled
> > 
> > According to the documentation I have, your CPU should
> be running at
> > 0.684 V (assuming it is a ULV variant), so in0 is
> Vcore. It does not
> > match cpu0_vid, but the other possible VID decoding
> table wouldn't
> > either. So I think that the VID pins are simply not
> properly routed to
> > your monitoring chip.
> > 
> > Ah, stupid me. Of course they aren't. The W83627HF
> only has 5 VID pins,
> > so you can't route a 6-bit VID value to it...
> > 
> > So basically this means that you can ignore the
> cpu0_vid value reported
> > by the w83627hf driver, it's bogus. Ideally the
> drivers would notice
> > the mismatch and wouldn't expose a VID value which
> can't be correct. I
> > don't have the time to fix it now so I've created a
> support ticket for
> > later:
> >   http://www.lm-sensors.org/ticket/2383
> > 
> > Could you please install the msr-tools package, load
> the msr driver,
> > and run as root:
> > # rdmsr -x 0x198
> > and report the result.
> > 
> > BTW you should also be able to use the via-cputemp
> driver. Didn't
> > sensors-detect suggest that?
> > 
> > > I looked into driver code and hwmon related code.
> All sensor data is exported to user space using sysfs.
> > > One thing I understood is there is no interrupt
> mechanism in sensor chip so we need to read data from chip's
> memory. So for periodic data we need to do polling at
> userspace (like sensord).
> > 
> > Yes, this is correct, except that _some_ devices
> actually support
> > interrupts. But libsensors currently doesn't support
> that, and most
> > drivers don't implement it anyway.
> > 
> > > Can I implement timer in driver and do polling in
> Kernel?
> > 
> > Technically you certainly can, but I very much doubt
> that such code
> > would be accepted in the kernel. If polling is
> necessary, then it is
> > better done in user-space than in the kernel, because
> user-space can
> > choose the polling set and period depending on the
> exact needs.
> > 
> > If you think that in-kernel polling has an advantage,
> please argue.
> > 
> > > What I want to do is get userspace event only
> when Alarm is raised. If I implement timer and netlink
> communication in driver will it be correct way to do it? As
> I do not find any other way.
> > 
> > I am no expert in this area, but I see no reason to go
> with netlink, it
> > seems to me that poll/select on the relevant alarm
> files themselves
> > should work. Guenter, I think you discussed this some
> times ago?
> > 
> Yes it does, assuming the driver performs some activity on
> those files,
> ie supports interrupts which trigger a file event. It is on
> my plate to update
> some of the hwmon drivers to support it, but I did not yet
> have the time
> to do it.
>  
> > Krunal, please also search for "poll notification" in
> > Documentation/hwmon/sysfs-interface. This suggests
> that a subset of the
> > attributes implement poll support already. I didn't
> look into this and
> > won't have time to do so, sorry.
> > 
> > But again this only applies to devices which raise
> interrupts on alarm,
> > so that no in-kernel polling is needed.
> > 
> Exactly.
> 
> Thanks,
> Guenter
> 

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

Re: [lm-sensors] sensor details for W83627HG-AW

[Jean Delvare]

On Wed, 22 Jun 2011 13:41:54 +0530 (IST), krunal patel wrote:
> --- On Tue, 21/6/11, Jean Delvare <khali@linux-fr.org> wrote:
> 
> > From: Jean Delvare <khali@linux-fr.org>
> > Subject: Re: [lm-sensors] sensor details for W83627HG-AW
> > To: "krunal patel" <krunal_smiles@yahoo.com>
> > Cc: lm-sensors@lm-sensors.org, "Guenter Roeck" <guenter.roeck@ericsson.com>
> > Date: Tuesday, 21 June, 2011, 5:20 PM
> > Could you please install the msr-tools package, load the msr driver,
> > and run as root:
> > # rdmsr -x 0x198
> > and report the result.
> > 
> Following is output you asked for
> # rdmsr -x 0x198        
> 400050004000500

OK, this is as I thought. The last two bytes are as documented in the
datasheet: 0x05 for 5 * 100 = 500 MHz and 0x00 for the lowest voltage
level. We might use the later to get cpu0_vid from the CPU itself, as
the monitoring ship won't be able to provide it.

> > BTW you should also be able to use the via-cputemp driver.
> > Didn't sensors-detect suggest that?
> > 
> I didn't used sensors-detect because it was wasting my time in resolving perl issues in my system. So I opened case, located chip and loaded related module.

I see. The via-cputemp driver probably doesn't exist in your kernel as
it was added with version 2.6.33. Can you please fetch the standalone
one at:
  http://khali.linux-fr.org/devel/misc/via-cputemp/
It should work. Please also update hwmon-vid from:
  http://khali.linux-fr.org/devel/misc/hwmon-vid/
I've updated it for your system. If these two drivers work well
together for you then I'll push the changes upstream.

-- 
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] sensor details for W83627HG-AW

[krunal patel]

Hi Jean,

after insmod hwmon-vid.ko and via-cputemp.ko output of sensors binary is

w83627hf-isa-0290
Adapter: ISA adapter
in0:          +0.70 V  (min =  +0.00 V, max =  +4.08 V)
in1:          +1.06 V  (min =  +0.00 V, max =  +4.08 V)
in2:          +3.30 V  (min =  +2.82 V, max =  +3.79 V)
in3:          +2.99 V  (min =  +3.57 V, max =  +2.02 V)  ALARM
in4:          +3.28 V  (min =  +1.98 V, max =  +4.05 V)
in5:          +3.31 V  (min =  +3.57 V, max =  +2.11 V)  ALARM
in6:          +3.33 V  (min =  +1.78 V, max =  +2.58 V)  ALARM
in7:          +3.31 V  (min =  +0.26 V, max =  +2.26 V)  ALARM
in8:          +3.52 V  (min =  +3.06 V, max =  +0.64 V)  ALARM
fan1:           0 RPM  (min = 3813 RPM, div = 2)  ALARM
fan2:           0 RPM  (min =   -1 RPM, div = 2)  ALARM
fan3:           0 RPM  (min =   -1 RPM, div = 2)  ALARM
temp1:        +52.0 C  (high =  +9.0 C, hyst = +32.0 C)  ALARM  sensor = thermistor
temp2:        +38.5 C  (high = +120.0 C, hyst = +115.0 C)  sensor = diode
temp3:        -48.0 C  (high = +120.0 C, hyst = +115.0 C)  sensor = thermistor
cpu0_vid:    +1.212 V
beep_enable: enabled

via_cputemp-isa-0000
Adapter: ISA adapter
Core 0:      +3892138.1 C  
cpu0_vid:    +0.684 V

--- On Wed, 22/6/11, Jean Delvare <khali@linux-fr.org> wrote:

> From: Jean Delvare <khali@linux-fr.org>
> Subject: Re: [lm-sensors] sensor details for W83627HG-AW
> To: "krunal patel" <krunal_smiles@yahoo.com>
> Cc: lm-sensors@lm-sensors.org, "Guenter Roeck" <guenter.roeck@ericsson.com>
> Date: Wednesday, 22 June, 2011, 9:30 PM
> On Wed, 22 Jun 2011 13:41:54 +0530
> (IST), krunal patel wrote:
> > --- On Tue, 21/6/11, Jean Delvare <khali@linux-fr.org>
> wrote:
> > 
> > > From: Jean Delvare <khali@linux-fr.org>
> > > Subject: Re: [lm-sensors] sensor details for
> W83627HG-AW
> > > To: "krunal patel" <krunal_smiles@yahoo.com>
> > > Cc: lm-sensors@lm-sensors.org,
> "Guenter Roeck" <guenter.roeck@ericsson.com>
> > > Date: Tuesday, 21 June, 2011, 5:20 PM
> > > Could you please install the msr-tools package,
> load the msr driver,
> > > and run as root:
> > > # rdmsr -x 0x198
> > > and report the result.
> > > 
> > Following is output you asked for
> > # rdmsr -x 0x198        
> > 400050004000500
> 
> OK, this is as I thought. The last two bytes are as
> documented in the
> datasheet: 0x05 for 5 * 100 = 500 MHz and 0x00 for the
> lowest voltage
> level. We might use the later to get cpu0_vid from the CPU
> itself, as
> the monitoring ship won't be able to provide it.
> 
> > > BTW you should also be able to use the
> via-cputemp driver.
> > > Didn't sensors-detect suggest that?
> > > 
> > I didn't used sensors-detect because it was wasting my
> time in resolving perl issues in my system. So I opened
> case, located chip and loaded related module.
> 
> I see. The via-cputemp driver probably doesn't exist in
> your kernel as
> it was added with version 2.6.33. Can you please fetch the
> standalone
> one at:
>   http://khali.linux-fr.org/devel/misc/via-cputemp/
> It should work. Please also update hwmon-vid from:
>   http://khali.linux-fr.org/devel/misc/hwmon-vid/
> I've updated it for your system. If these two drivers work
> well
> together for you then I'll push the changes upstream.
> 
> -- 
> Jean Delvare
> http://khali.linux-fr.org/wishlist.html
> 


Regards,
Krunal

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

Re: [lm-sensors] sensor details for W83627HG-AW

[Jean Delvare]

Hi Krunal,

On Fri, 24 Jun 2011 16:49:13 +0530 (IST), krunal patel wrote:
> after insmod hwmon-vid.ko and via-cputemp.ko output of sensors binary is
> (...)
> via_cputemp-isa-0000
> Adapter: ISA adapter
> Core 0:      +3892138.1 C  
> cpu0_vid:    +0.684 V

Thanks for the report. cpu0_vid looks very good, so I'll push my
patches upstream. I can credit you as a tester if you want, but beware
that your e-mail address would then be published in the kernel
repository, which could result in more spam.

Temperature looks plain wrong though. Does the number change over time?

Can you please provide the output of:
# rdmsr -x 0x1169
both when idle and under load?

Looking at the code, I don't even see how the temperature value could
be a non-integer, so there must be an overflow somewhere.

-- 
Jean Delvare

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

Re: [lm-sensors] sensor details for W83627HG-AW

[krunal patel]

Hi Jean,

--- On Mon, 27/6/11, Jean Delvare <khali@linux-fr.org> wrote:

> From: Jean Delvare <khali@linux-fr.org>
> Subject: Re: [lm-sensors] sensor details for W83627HG-AW
> To: "krunal patel" <krunal_smiles@yahoo.com>
> Cc: lm-sensors@lm-sensors.org, "Guenter Roeck" <guenter.roeck@ericsson.com>
> Date: Monday, 27 June, 2011, 8:32 PM
> Hi Krunal,
> 
> On Fri, 24 Jun 2011 16:49:13 +0530 (IST), krunal patel
> wrote:
> > after insmod hwmon-vid.ko and via-cputemp.ko output of
> sensors binary is
> > (...)
> > via_cputemp-isa-0000
> > Adapter: ISA adapter
> > Core 0:      +3892138.1 C  
> > cpu0_vid:    +0.684 V
> 
> Thanks for the report. cpu0_vid looks very good, so I'll
> push my
> patches upstream. I can credit you as a tester if you want,
> but beware
> that your e-mail address would then be published in the
> kernel
> repository, which could result in more spam.
I will left this on you. :). I will try that my name comes in developer list in future. :)
> 
> Temperature looks plain wrong though. Does the number
> change over time?
>
Temperature values are constant in via_cputemp-isa-0000 output but it changes in w83627hf-isa-0290 output when I run cpuburn like binary.
> Can you please provide the output of:
> # rdmsr -x 0x1169
> both when idle and under load?
> 
# rdmsr -x 0x1169
ffff50
> Looking at the code, I don't even see how the temperature
> value could
> be a non-integer, so there must be an overflow somewhere.
> 
> -- 
> Jean Delvare
> 

Regards,
Krunal

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

Re: [lm-sensors] sensor details for W83627HG-AW

[Jean Delvare]

On Fri, 24 Jun 2011 16:49:13 +0530 (IST), krunal patel wrote:
> after insmod hwmon-vid.ko and via-cputemp.ko output of sensors binary is

Can you please report the messages in the kernel log when you load both
drivers?

-- 
Jean Delvare

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

Re: [lm-sensors] sensor details for W83627HG-AW

[krunal patel]

Hi Jean,



--- On Thu, 30/6/11, Jean Delvare <khali@linux-fr.org> wrote:

> From: Jean Delvare <khali@linux-fr.org>
> Subject: Re: [lm-sensors] sensor details for W83627HG-AW
> To: "krunal patel" <krunal_smiles@yahoo.com>
> Cc: lm-sensors@lm-sensors.org, "Guenter Roeck" <guenter.roeck@ericsson.com>
> Date: Thursday, 30 June, 2011, 5:50 PM
> On Fri, 24 Jun 2011 16:49:13 +0530
> (IST), krunal patel wrote:
> > after insmod hwmon-vid.ko and via-cputemp.ko output of
> sensors binary is
> 
> Can you please report the messages in the kernel log when
> you load both
> drivers?
> 
> -- 
> Jean Delvare
> 
dmesg output:
--------------
Using 6-bit VID table for VIA C7-D CPU


Best Regards,
Krunal Patel

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

Re: [lm-sensors] sensor details for W83627HG-AW

[Jean Delvare]

Hi Krunal,

On Sat, 2 Jul 2011 16:11:45 +0530 (IST), krunal patel wrote:
> --- On Thu, 30/6/11, Jean Delvare <khali@linux-fr.org> wrote:
> > Can you please report the messages in the kernel log when
> > you load both drivers?
>
> dmesg output:
> --------------
> Using 6-bit VID table for VIA C7-D CPU

Hmm, are you sure this is with the latest version of the drivers? The
above is what the previous version would have printed. The new version
should mention Eden instead of C7-D.

-- 
Jean Delvare

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