[lm-sensors] Gigabyte GA-P35-DS3P - VID Zero value

[lm-sensors] Gigabyte GA-P35-DS3P - VID Zero value

[Simon Wilson]

I am soooo close to getting this working properly.

I have a GA-P35-DS3P motherboard, with an E6850 Core 2 Duo processor.  
The machine is running CentOS 5.3. It has an it8718 sensors chip.

I have installed lm_sensors 2.10.8 and the kmod-it87 driver from  
elrepo.org (needed because of the 'old' CentOS 2.6.18 kernel), and all  
is basically working. A clear sensors output reads:

it8718-isa-0290
Adapter: ISA adapter
in0:       +1.12 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
in1:       +1.87 V  (min =  +1.71 V, max =  +1.89 V)
in2:       +3.22 V  (min =  +3.14 V, max =  +3.47 V)
in3:       +2.91 V  (min =  +2.83 V, max =  +3.12 V)
in4:       +0.85 V  (min =  +2.85 V, max =  +3.15 V)   ALARM
in5:       +0.05 V  (min =  +0.85 V, max =  +1.09 V)   ALARM
in6:       +0.03 V  (min =  +1.12 V, max =  +1.28 V)   ALARM
in7:       +3.12 V  (min =  +2.85 V, max =  +3.15 V)
in8:       +3.30 V
fan1:     1424 RPM  (min =  600 RPM)
fan2:        0 RPM  (min = 3994 RPM)
fan3:        0 RPM  (min =    0 RPM)
fan4:        0 RPM  (min =    0 RPM)
temp1:       +30°C  (low  =   +10°C, high =   +60°C)   sensor = thermistor
temp2:       +26°C  (low  =   +10°C, high =   +70°C)   sensor = diode
temp3:        -2°C  (low  =  +127°C, high =  +127°C)   sensor = disabled
vid:      +0.000 V

Using the configuration from  
http://www.lm-sensors.org/wiki/Configurations/Gigabyte/G33-DS3R which  
also uses the 8718 I am now at this:

it8718-isa-0290
Adapter: ISA adapter
Vcore:     +1.04 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
Vram:      +1.87 V  (min =  +1.71 V, max =  +1.89 V)
+3.3V:     +3.22 V  (min =  +3.14 V, max =  +3.47 V)
+5V:       +4.89 V  (min =  +4.76 V, max =  +5.24 V)
+12V:     +12.48 V  (min = +11.39 V, max = +12.61 V)
Vbat:      +3.30 V
CPU Fan:  1421 RPM  (min =  600 RPM)
NBr Temp:    +30°C  (low  =   +10°C, high =   +60°C)   sensor = thermistor
CPU Temp:    +26°C  (low  =   +10°C, high =   +70°C)   sensor = diode
vid:      +0.000 V

Which is perfect apart from one thing - the 0.000 V value for VID,  
which is then also throwing off Vcore (in0) as that is calculated from  
VID (>95 <105%).

Can anyone help me work out why VID is reading 0.000?

Thanks



-- 
Simon Wilson
www.simonandkate.net

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

Re: [lm-sensors] Gigabyte GA-P35-DS3P - VID Zero value

[Justin Piszcz]

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



On Mon, 19 Oct 2009, Simon Wilson wrote:

> I am soooo close to getting this working properly.
>
> I have a GA-P35-DS3P motherboard, with an E6850 Core 2 Duo processor. The 
> machine is running CentOS 5.3. It has an it8718 sensors chip.
>
> I have installed lm_sensors 2.10.8 and the kmod-it87 driver from elrepo.org 
> (needed because of the 'old' CentOS 2.6.18 kernel), and all is basically 
> working. A clear sensors output reads:
>
> it8718-isa-0290
> Adapter: ISA adapter
> in0:       +1.12 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
> in1:       +1.87 V  (min =  +1.71 V, max =  +1.89 V)
> in2:       +3.22 V  (min =  +3.14 V, max =  +3.47 V)
> in3:       +2.91 V  (min =  +2.83 V, max =  +3.12 V)
> in4:       +0.85 V  (min =  +2.85 V, max =  +3.15 V)   ALARM
> in5:       +0.05 V  (min =  +0.85 V, max =  +1.09 V)   ALARM
> in6:       +0.03 V  (min =  +1.12 V, max =  +1.28 V)   ALARM
> in7:       +3.12 V  (min =  +2.85 V, max =  +3.15 V)
> in8:       +3.30 V
> fan1:     1424 RPM  (min =  600 RPM)
> fan2:        0 RPM  (min = 3994 RPM)
> fan3:        0 RPM  (min =    0 RPM)
> fan4:        0 RPM  (min =    0 RPM)
> temp1:       +30°C  (low  =   +10°C, high =   +60°C)   sensor = thermistor
> temp2:       +26°C  (low  =   +10°C, high =   +70°C)   sensor = diode
> temp3:        -2°C  (low  =  +127°C, high =  +127°C)   sensor = disabled
> vid:      +0.000 V
>
> Using the configuration from 
> http://www.lm-sensors.org/wiki/Configurations/Gigabyte/G33-DS3R which also 
> uses the 8718 I am now at this:
>
> it8718-isa-0290
> Adapter: ISA adapter
> Vcore:     +1.04 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
> Vram:      +1.87 V  (min =  +1.71 V, max =  +1.89 V)
> +3.3V:     +3.22 V  (min =  +3.14 V, max =  +3.47 V)
> +5V:       +4.89 V  (min =  +4.76 V, max =  +5.24 V)
> +12V:     +12.48 V  (min = +11.39 V, max = +12.61 V)
> Vbat:      +3.30 V
> CPU Fan:  1421 RPM  (min =  600 RPM)
> NBr Temp:    +30°C  (low  =   +10°C, high =   +60°C)   sensor = thermistor
> CPU Temp:    +26°C  (low  =   +10°C, high =   +70°C)   sensor = diode
> vid:      +0.000 V
>
> Which is perfect apart from one thing - the 0.000 V value for VID, which is 
> then also throwing off Vcore (in0) as that is calculated from VID (>95 
> <105%).
>
> Can anyone help me work out why VID is reading 0.000?
>
> Thanks

Hi,

I have the same board and would like to know as well, my output:

it8718-isa-0290
Adapter: ISA adapter
in0:         +1.57 V  (min =  +0.00 V, max =  +4.08 V) 
in1:         +2.11 V  (min =  +0.00 V, max =  +4.08 V) 
in2:         +3.23 V  (min =  +0.00 V, max =  +4.08 V) 
in3:         +2.93 V  (min =  +0.00 V, max =  +4.08 V) 
in4:         +0.86 V  (min =  +0.00 V, max =  +4.08 V) 
in5:         +0.08 V  (min =  +0.00 V, max =  +4.08 V) 
in6:         +0.16 V  (min =  +0.00 V, max =  +4.08 V) 
in7:         +3.09 V  (min =  +0.00 V, max =  +4.08 V) 
Vbat:        +3.28 V
fan1:          0 RPM  (min =    0 RPM)
fan2:          0 RPM  (min =    0 RPM)
fan3:       1117 RPM  (min =    0 RPM)
fan4:       1102 RPM  (min =    0 RPM)
temp1:       +46.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp2:       +35.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermal diode
temp3:        -2.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
cpu0_vid:   +0.000 V

Justin.

[-- 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] Gigabyte GA-P35-DS3P - VID Zero value

[Adam Nielsen]

> I have the same board and would like to know as well, my output:

Well as long as we're comparing outputs I have a GA-P35-DS4 and my output
looks much the same:

it8718-isa-0290
Adapter: ISA adapter
in0:         +1.25 V  (min =  +0.00 V, max =  +4.08 V)
in1:         +1.87 V  (min =  +0.00 V, max =  +4.08 V)
in2:         +3.33 V  (min =  +0.00 V, max =  +4.08 V)
in3:         +3.01 V  (min =  +0.00 V, max =  +4.08 V)
in4:         +0.46 V  (min =  +0.00 V, max =  +4.08 V)
in5:         +0.06 V  (min =  +0.00 V, max =  +4.08 V)
in6:         +0.10 V  (min =  +0.00 V, max =  +4.08 V)
in7:         +3.04 V  (min =  +0.00 V, max =  +4.08 V)
in8:         +3.28 V
fan1:       1973 RPM  (min =   10 RPM)
fan2:       1229 RPM  (min =    0 RPM)
fan3:       1225 RPM  (min =    0 RPM)
fan4:       1231 RPM  (min =    0 RPM)
temp1:       +41.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp2:       +42.0°C  (low  = +127.0°C, high = +60.0°C)  sensor = thermal diode
temp3:        -2.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
cpu0_vid:   +0.000 V

As far as I can gather, it's because the hwmon-vid module doesn't recognise my
CPU.  Which is odd, because I don't have a message in my logs indicating so.
My kernel is 2.6.30 which is a little on the old side now, but looking at the
latest git kernel there doesn't seem to be any mention of the Intel Core2 series.

Am I reading that right?  This is my CPU:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz
stepping        : 11
cpu MHz         : 2997.028
cache size      : 4096 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 4
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx est
tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow vnmi flexpriority
bogomips        : 5993.91
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

Cheers,
Adam.

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

Re: [lm-sensors] Gigabyte GA-P35-DS3P - VID Zero value

[Simon Wilson]

Quoting Simon Wilson <simon@simonandkate.net>:

> I have a GA-P35-DS3P motherboard, with an E6850 Core 2 Duo  
> processor. The machine is running CentOS 5.3. It has an it8718  
> sensors chip.
>
> I have installed lm_sensors 2.10.8 and the kmod-it87 driver from  
> elrepo.org (needed because of the 'old' CentOS 2.6.18 kernel), and  
> all is basically working. A clear sensors output reads:
>
> it8718-isa-0290
> Adapter: ISA adapter
> in0:       +1.12 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
> in1:       +1.87 V  (min =  +1.71 V, max =  +1.89 V)
> in2:       +3.22 V  (min =  +3.14 V, max =  +3.47 V)
> in3:       +2.91 V  (min =  +2.83 V, max =  +3.12 V)
> in4:       +0.85 V  (min =  +2.85 V, max =  +3.15 V)   ALARM
> in5:       +0.05 V  (min =  +0.85 V, max =  +1.09 V)   ALARM
> in6:       +0.03 V  (min =  +1.12 V, max =  +1.28 V)   ALARM
> in7:       +3.12 V  (min =  +2.85 V, max =  +3.15 V)
> in8:       +3.30 V
> fan1:     1424 RPM  (min =  600 RPM)
> fan2:        0 RPM  (min = 3994 RPM)
> fan3:        0 RPM  (min =    0 RPM)
> fan4:        0 RPM  (min =    0 RPM)
> temp1:       +30°C  (low  =   +10°C, high =   +60°C) sensor = thermistor
> temp2:       +26°C  (low  =   +10°C, high =   +70°C) sensor = diode
> temp3:        -2°C  (low  =  +127°C, high =  +127°C) sensor = disabled
> vid:      +0.000 V
>
> Using the configuration from  
> http://www.lm-sensors.org/wiki/Configurations/Gigabyte/G33-DS3R  
> which also uses the 8718 I am now at this:
>
> it8718-isa-0290
> Adapter: ISA adapter
> Vcore:     +1.04 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
> Vram:      +1.87 V  (min =  +1.71 V, max =  +1.89 V)
> +3.3V:     +3.22 V  (min =  +3.14 V, max =  +3.47 V)
> +5V:       +4.89 V  (min =  +4.76 V, max =  +5.24 V)
> +12V:     +12.48 V  (min = +11.39 V, max = +12.61 V)
> Vbat:      +3.30 V
> CPU Fan:  1421 RPM  (min =  600 RPM)
> NBr Temp:    +30°C  (low  =   +10°C, high =   +60°C) sensor = thermistor
> CPU Temp:    +26°C  (low  =   +10°C, high =   +70°C) sensor = diode
> vid:      +0.000 V
>
> Which is perfect apart from one thing - the 0.000 V value for VID,  
> which is then also throwing off Vcore (in0) as that is calculated  
> from VID (>95 <105%).
>
> Can anyone help me work out why VID is reading 0.000?
>
> Thanks

This is the same issue as noted in this thread here:

http://lists.lm-sensors.org/pipermail/lm-sensors/2009-January/025018.html

Setting /sys/class/hwmon/hwmon0/device/vrm to 100 instead of 110  
"fixes" this issue. Or I should say, it means I get a value - 1.088 V  
- at VID. Whether it is right or not... ?

Running "isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 7" as asked in that  
thread gives me:

WARNING! Running this program can cause system crashes, data loss and worse!
I will probe address register 0x2e and data register 0x2f.
Probing bank 7 using bank register 0x07.
Continue? [Y/n] y
      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 87 18 04 10 00 80 df 3f 43 89 00 00 1d 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 c2 00 00 00 00 00 00
c0: 80 1d 3f 43 09 00 00 00 00 19 00 03 08 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7e
f0: 10 40 00 00 00 00 11 00 00 00 00 00 3f 00 00 00



 From reading that thread I wonder if this is a version of hwmon-vid issue?

-- 
Simon Wilson
www.simonandkate.net

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

Re: [lm-sensors] Gigabyte GA-P35-DS3P - VID Zero value

[Adam Nielsen]

> Setting /sys/class/hwmon/hwmon0/device/vrm to 100 instead of 110 "fixes"
> this issue. Or I should say, it means I get a value - 1.088 V - at VID.
> Whether it is right or not... ?

I suspect it is wrong - I was looking at this issue this morning and the
Core2 CPUs are correctly listed in the hwmon-vid driver and I too get a
vrm value of 110 which is correct for my CPU.  Setting a different vrm
value causes a different formula to be used when calculating the voltage.

I was wondering whether the VID lines aren't actually connected to the
it87 chip, but it looks like they are, just not all of them.

It looks like (if that's correct) the only option is to hack hwmon-vid
to use less VID pins or something to get the correct value out.

Cheers,
Adam.

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

Re: [lm-sensors] Gigabyte GA-P35-DS3P - VID Zero value

[Simon Wilson]

Quoting Adam Nielsen <a.nielsen@shikadi.net>:

>> Setting /sys/class/hwmon/hwmon0/device/vrm to 100 instead of 110 "fixes"
>> this issue. Or I should say, it means I get a value - 1.088 V - at VID.
>> Whether it is right or not... ?
>
> I suspect it is wrong - I was looking at this issue this morning and the
> Core2 CPUs are correctly listed in the hwmon-vid driver and I too get a
> vrm value of 110 which is correct for my CPU.  Setting a different vrm
> value causes a different formula to be used when calculating the voltage.
>
> I was wondering whether the VID lines aren't actually connected to the
> it87 chip, but it looks like they are, just not all of them.
>
> It looks like (if that's correct) the only option is to hack hwmon-vid
> to use less VID pins or something to get the correct value out.
>

hwmon-vid.h on my box contains (intro comments excluded for brevity):

#ifndef _LINUX_HWMON_VID_H
#define _LINUX_HWMON_VID_H

int vid_from_reg(int val, u8 vrm);
u8 vid_which_vrm(void);

/* vrm is the VRM/VRD document version multiplied by 10.
    val is in mV to avoid floating point in the kernel.
    Returned value is the 4-, 5- or 6-bit VID code.
    Note that only VRM 9.x is supported for now. */
static inline int vid_to_reg(int val, u8 vrm)
{
         switch (vrm) {
         case 91:                /* VRM 9.1 */
         case 90:                /* VRM 9.0 */
                 return ((val >= 1100) && (val <= 1850) ?
                         ((18499 - val * 10) / 25 + 5) / 10 : -1);
         default:
                 return -1;
         }
}

#endif /* _LINUX_HWMON_VID_H */


The file is dated Sept 20 2006. I suspect this may be the issue...  
there is nothing in there for VRM 10 or 11. It would appear that I  
need a later hwmon-vid driver? Or am I completely on the wrong track  
there LOL...

As you say, the info is definitely there to be read - according to  
http://lists.lm-sensors.org/pipermail/lm-sensors/2008-October/024581.html the  
IT8718F does have VID info, but it is stored differently:

"The IT8718F and IT8720F also features VID inputs (up to 8 pins) but  
the value is stored in the Super-I/O configuration space. Due to  
technical limitations, this value can currently only be read once at  
initialization time, so the driver won't notice and report changes in  
the VID value. The two upper VID bits share their pins with voltage  
inputs (in5 and in6) so you can't have both on a given board."

Simon.



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

Re: [lm-sensors] Gigabyte GA-P35-DS3P - VID Zero value

[Adam Nielsen]

> The file is dated Sept 20 2006. I suspect this may be the issue... there
> is nothing in there for VRM 10 or 11. It would appear that I need a
> later hwmon-vid driver? Or am I completely on the wrong track there LOL...

That's only your installed header file.  It would only affect userspace
programs doing the conversion themselves.  The latest code from the
kernel module is at:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/hwmon/hwmon-vid.c;hb=HEAD

And all the VID revisions are defined in there.

> As you say, the info is definitely there to be read - according to
> http://lists.lm-sensors.org/pipermail/lm-sensors/2008-October/024581.html
> the IT8718F does have VID info, but it is stored differently:
> 
> "The IT8718F and IT8720F also features VID inputs (up to 8 pins) but the
> value is stored in the Super-I/O configuration space. Due to technical
> limitations, this value can currently only be read once at
> initialization time, so the driver won't notice and report changes in
> the VID value. The two upper VID bits share their pins with voltage
> inputs (in5 and in6) so you can't have both on a given board."

Well it looks like the value isn't being read properly during chip
initialisation.  Perhaps a bug in the it87 hwmon driver?

The VID seems to get read in around line 1037:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/hwmon/it87.c#l1035

Probably more research required to figure out why that value is zero on
our motherboards.

Cheers,
Adam.


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

Re: [lm-sensors] Gigabyte GA-P35-DS3P - VID Zero value

[Simon Wilson]

Quoting Adam Nielsen <a.nielsen@shikadi.net>:

>> The file is dated Sept 20 2006. I suspect this may be the issue... there
>> is nothing in there for VRM 10 or 11. It would appear that I need a
>> later hwmon-vid driver? Or am I completely on the wrong track there LOL...
>
> That's only your installed header file.  It would only affect userspace
> programs doing the conversion themselves.  The latest code from the
> kernel module is at:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;  
> =drivers/hwmon/hwmon-vid.c;hb=HEAD
>
> And all the VID revisions are defined in there.
>
> Well it looks like the value isn't being read properly during chip
> initialisation.  Perhaps a bug in the it87 hwmon driver?
>
> The VID seems to get read in around line 1037:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;  
> =drivers/hwmon/it87.c#l1035
>
> Probably more research required to figure out why that value is zero on
> our motherboards.
>
> Cheers,
> Adam.
>

Thanks for clarifying that. Still new at all this stuff really... :)

Well, based on the git version of hwmon-vid.c the fact that  
/sys/class/hwmon/hwmon0/device/vrm is originally 110 on my system  
would seem to indicate then that the hwmon-vid driver is correctly  
setting the VRM version based on my Conroe CPU to 110. Is there any  
way to interrogate the hwmon-vid driver to see whether it is working  
at a lower level before the it87 driver reads it in?

Perhaps the elrepo.org kmod-it87 driver that I am using needs to be  
updated with more recent code to support the different VID  
configuration of the 8718 and 8720 chips...

Simon.

-- 
Simon Wilson
www.simonandkate.net

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

Re: [lm-sensors] Gigabyte GA-P35-DS3P - VID Zero value

[Adam Nielsen]

> Thanks for clarifying that. Still new at all this stuff really... :)

That makes two of us ;-)

> Well, based on the git version of hwmon-vid.c the fact that
> /sys/class/hwmon/hwmon0/device/vrm is originally 110 on my system would
> seem to indicate then that the hwmon-vid driver is correctly setting the
> VRM version based on my Conroe CPU to 110. Is there any way to
> interrogate the hwmon-vid driver to see whether it is working at a lower
> level before the it87 driver reads it in?

All the hwmon-vid driver seems to do is ask the driver for the raw vid value
and run it through a formula.  It doesn't actually have anything to do with
hardware at all (other than detecting the CPU brand and model.)

> Perhaps the elrepo.org kmod-it87 driver that I am using needs to be
> updated with more recent code to support the different VID configuration
> of the 8718 and 8720 chips...

Quite possibly, but if you download the latest Linux kernel, compile and boot
that, and try again you'll know for sure whether code exists to handle it or
not.  Given the number of quirks motherboard sensors seem to have, I suspect
this issue is just another quirk that needs to be added to the it87 driver.

The next step is to probably get some raw vid values off the it87 chip to see
what they look like - if those are all zero then we know the lines aren't
connected, but if there are some values there it should in theory be possible
to map them to vid voltages.  I guess this is where that isadump output you
posted comes in...

It's a shame there's no "passthrough" vrm version that disables the formula
and shows the raw vid value, as that would probably be quite helpful.  Maybe
it's worth adding a patch to do just that?

Cheers,
Adam.

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

Re: [lm-sensors] Gigabyte GA-P35-DS3P - VID Zero value

[Simon Wilson]

Quoting Adam Nielsen <a.nielsen@shikadi.net>:


> All the hwmon-vid driver seems to do is ask the driver for the raw vid value
> and run it through a formula.  It doesn't actually have anything to do with
> hardware at all (other than detecting the CPU brand and model.)
>
> Quite possibly, but if you download the latest Linux kernel, compile and boot
> that, and try again you'll know for sure whether code exists to handle it or
> not.  Given the number of quirks motherboard sensors seem to have, I suspect
> this issue is just another quirk that needs to be added to the it87 driver.
>
> The next step is to probably get some raw vid values off the it87 chip to see
> what they look like - if those are all zero then we know the lines aren't
> connected, but if there are some values there it should in theory be possible
> to map them to vid voltages.  I guess this is where that isadump output you
> posted comes in...
>
> It's a shame there's no "passthrough" vrm version that disables the formula
> and shows the raw vid value, as that would probably be quite helpful.  Maybe
> it's worth adding a patch to do just that?
>
> Cheers,
> Adam.
>
>

Phil from elrepo assures me that the kmod-it87 driver has all the  
latest patches backported, so it's not that.

Interpreting the isadump is way over my head, so it looks like we're  
on a hiding to nowhere here unless someone can assist us with that and  
investigating hwmon-vid.

I won't be doing a kernel upgrade - this is a CentOS server that runs  
my family email, web site, etc... I try and keep downtime and reboots  
to a bare minimum. :)

As to a patch for VRM 'passthrough' - again, way over my level of  
expertise I'm afraid. :(

What is interesting is that there is obviously a value being obtained  
from the motherboard - otherwise setting VRM to 100 (10.0) would also  
produce 0.000 V. But the calculation that it is running when the value  
is 110 (11.0) is resulting in a 0 value. So somehow, the formulae and  
cals in teh VRM translation is screwy when hwmon (correctly) detects  
my Conroe and sets it to 11.0.

Cheers
Simon

-- 
Simon Wilson
www.simonandkate.net

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

Re: [lm-sensors] Gigabyte GA-P35-DS3P - VID Zero value

[Jean Delvare]

Hi Simon,

On Tue, 20 Oct 2009 09:35:43 +1000, Simon Wilson wrote:
> Quoting Simon Wilson <simon@simonandkate.net>:
> 
> > I have a GA-P35-DS3P motherboard, with an E6850 Core 2 Duo  
> > processor. The machine is running CentOS 5.3. It has an it8718  
> > sensors chip.
> >
> > I have installed lm_sensors 2.10.8 and the kmod-it87 driver from  
> > elrepo.org (needed because of the 'old' CentOS 2.6.18 kernel), and  
> > all is basically working. A clear sensors output reads:
> >
> > it8718-isa-0290
> > Adapter: ISA adapter
> > in0:       +1.12 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
> > in1:       +1.87 V  (min =  +1.71 V, max =  +1.89 V)
> > in2:       +3.22 V  (min =  +3.14 V, max =  +3.47 V)
> > in3:       +2.91 V  (min =  +2.83 V, max =  +3.12 V)
> > in4:       +0.85 V  (min =  +2.85 V, max =  +3.15 V)   ALARM
> > in5:       +0.05 V  (min =  +0.85 V, max =  +1.09 V)   ALARM
> > in6:       +0.03 V  (min =  +1.12 V, max =  +1.28 V)   ALARM
> > in7:       +3.12 V  (min =  +2.85 V, max =  +3.15 V)
> > in8:       +3.30 V
> > fan1:     1424 RPM  (min =  600 RPM)
> > fan2:        0 RPM  (min = 3994 RPM)
> > fan3:        0 RPM  (min =    0 RPM)
> > fan4:        0 RPM  (min =    0 RPM)
> > temp1:       +30°C  (low  =   +10°C, high =   +60°C) sensor = thermistor
> > temp2:       +26°C  (low  =   +10°C, high =   +70°C) sensor = diode
> > temp3:        -2°C  (low  =  +127°C, high =  +127°C) sensor = disabled
> > vid:      +0.000 V
> >
> > Using the configuration from  
> > http://www.lm-sensors.org/wiki/Configurations/Gigabyte/G33-DS3R  
> > which also uses the 8718 I am now at this:
> >
> > it8718-isa-0290
> > Adapter: ISA adapter
> > Vcore:     +1.04 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
> > Vram:      +1.87 V  (min =  +1.71 V, max =  +1.89 V)
> > +3.3V:     +3.22 V  (min =  +3.14 V, max =  +3.47 V)
> > +5V:       +4.89 V  (min =  +4.76 V, max =  +5.24 V)
> > +12V:     +12.48 V  (min = +11.39 V, max = +12.61 V)
> > Vbat:      +3.30 V
> > CPU Fan:  1421 RPM  (min =  600 RPM)
> > NBr Temp:    +30°C  (low  =   +10°C, high =   +60°C) sensor = thermistor
> > CPU Temp:    +26°C  (low  =   +10°C, high =   +70°C) sensor = diode
> > vid:      +0.000 V
> >
> > Which is perfect apart from one thing - the 0.000 V value for VID,  
> > which is then also throwing off Vcore (in0) as that is calculated  
> > from VID (>95 <105%).
> >
> > Can anyone help me work out why VID is reading 0.000?
> >
> > Thanks
> 
> This is the same issue as noted in this thread here:
> 
> http://lists.lm-sensors.org/pipermail/lm-sensors/2009-January/025018.html
> 
> Setting /sys/class/hwmon/hwmon0/device/vrm to 100 instead of 110  
> "fixes" this issue. Or I should say, it means I get a value - 1.088 V  
> - at VID. Whether it is right or not... ?
> 
> Running "isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 7" as asked in that  
> thread gives me:
> 
> WARNING! Running this program can cause system crashes, data loss and worse!
> I will probe address register 0x2e and data register 0x2f.
> Probing bank 7 using bank register 0x07.
> Continue? [Y/n] y
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00: 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 87 18 04 10 00 80 df 3f 43 89 00 00 1d 00 00 00
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 60: 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00
> 70: 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00
> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> b0: 00 00 00 00 00 00 00 00 00 c2 00 00 00 00 00 00
> c0: 80 1d 3f 43 09 00 00 00 00 19 00 03 08 00 00 00
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7e
> f0: 10 40 00 00 00 00 11 00 00 00 00 00 3f 00 00 00

The raw VID value is at 0xfc, value is 0x3f, which means all VID pins
are high. Which means they are not wired to the CPU, otherwise at least
one of them would be low.

Now, looking at register 0x27, it appears that all VID input pins have
been configured for their alternative function (GPIO.) This is not the
default value for this register, which means that the motherboard
vendor decided to not use these pins for VID input but for another
function.

BTW... the pins in question are in input mode. So who knows... maybe
they ARE used for VID monitoring, and GPIO was preferred over true VID
for obscure reasons (incompatible voltage levels?) You may want to run,
as root:

isadump -f 0x800 16

and see if the 3rd value would make sense as a VID value for your CPU.

>  From reading that thread I wonder if this is a version of hwmon-vid issue?

Not, it's not. The VID input pins apparently aren't wired on your
motherboard, or wired in a weird way. Ask the manufacturer to confirm
this, and if they do, blame it on them. There's nothing hwmon-vid can
do about it.

One thing we could do is teach the it87 driver to not export the VID
value if any of VID pins 0-3 are configured for GPIO function. That
wouldn't be too difficult, but would you be able to test a kernel patch?

-- 
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] Gigabyte GA-P35-DS3P - VID Zero value

[Jean Delvare]

Hi Adam,

On Tue, 20 Oct 2009 21:03:50 +1000, Adam Nielsen wrote:
> It's a shame there's no "passthrough" vrm version that disables the formula
> and shows the raw vid value, as that would probably be quite helpful.  Maybe
> it's worth adding a patch to do just that?

This is an interesting idea, however there is a technical problem:
different CPU models have a different number of VID pins. If you need
the pass-through mode, it means the kernel doesn't know about your CPU
model, so it doesn't know how many bits should be read from the chip
and exported.

Another problem is the voltage levels. Different VRM standards use
different voltage levels. Some chips support different modes through
configuration, and the right mode depends on the CPU family. In a
perfect world the BIOS would set it up properly, but experience as
shown this isn't always the case, and as a result some of our drivers
change the mode based on the CPU model. This can't be done if VID
decoding is done in user-space.

So I'm not saying pass-through VID values are a bad idea... but if you
want to implement this, it's not a one-hour hack. It will take some
thoughts and time.

-- 
Jean Delvare

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

Re: [lm-sensors] Gigabyte GA-P35-DS3P - VID Zero value

[Adam Nielsen]

> The raw VID value is at 0xfc, value is 0x3f, which means all VID pins
> are high. Which means they are not wired to the CPU, otherwise at least
> one of them would be low.
> 
> Now, looking at register 0x27, it appears that all VID input pins have
> been configured for their alternative function (GPIO.) This is not the
> default value for this register, which means that the motherboard
> vendor decided to not use these pins for VID input but for another
> function.
> 
> BTW... the pins in question are in input mode. So who knows... maybe
> they ARE used for VID monitoring, and GPIO was preferred over true VID
> for obscure reasons (incompatible voltage levels?) You may want to run,
> as root:
> 
> isadump -f 0x800 16
> 
> and see if the 3rd value would make sense as a VID value for your CPU.

Ah interesting.  It doesn't seem to for me though:

       0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
0800: ff 01 cf fa f7 07 ff ff ff ff ff ff ff ff ff ff

VRM v11 (in hwmon-vid) says values can't be > 0xb2, although I don't know how
many bits are wired up to the VID.

So is 0x802 the GPIO input?  I wonder what it's wired up to...?

> One thing we could do is teach the it87 driver to not export the VID
> value if any of VID pins 0-3 are configured for GPIO function. That
> wouldn't be too difficult, but would you be able to test a kernel patch?

I can test an it87 patch if you need a guinea pig - especially if it'll
compile against 2.6.30 so I don't have to reboot ;-)

Cheers,
Adam.

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

Re: [lm-sensors] Gigabyte GA-P35-DS3P - VID Zero value

[Jean Delvare]

On Tue, 20 Oct 2009 21:23:09 +1000, Simon Wilson wrote:
> Interpreting the isadump is way over my head, so it looks like we're  
> on a hiding to nowhere here unless someone can assist us with that and  
> investigating hwmon-vid.

See my reply to your original post.

> What is interesting is that there is obviously a value being obtained  
> from the motherboard - otherwise setting VRM to 100 (10.0) would also  
> produce 0.000 V.

This is an incorrect assumption. VID decoding is tricky and you really
cannot assume anything like that. Only the raw VID value holds the
truth.

> But the calculation that it is running when the value  
> is 110 (11.0) is resulting in a 0 value. So somehow, the formulae and  
> cals in the VRM translation is screwy when hwmon (correctly) detects  
> my Conroe and sets it to 11.0.

Your register dump makes it pretty clear that there is no VID value to
be read in the first place. At least not from the VID value register
0xfc).

-- 
Jean Delvare

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

Re: [lm-sensors] Gigabyte GA-P35-DS3P - VID Zero value

[Jean Delvare]

Hi Adam,

On Tue, 20 Oct 2009 21:50:31 +1000, Adam Nielsen wrote:
> > The raw VID value is at 0xfc, value is 0x3f, which means all VID pins
> > are high. Which means they are not wired to the CPU, otherwise at least
> > one of them would be low.
> > 
> > Now, looking at register 0x27, it appears that all VID input pins have
> > been configured for their alternative function (GPIO.) This is not the
> > default value for this register, which means that the motherboard
> > vendor decided to not use these pins for VID input but for another
> > function.
> > 
> > BTW... the pins in question are in input mode. So who knows... maybe
> > they ARE used for VID monitoring, and GPIO was preferred over true VID
> > for obscure reasons (incompatible voltage levels?) You may want to run,
> > as root:
> > 
> > isadump -f 0x800 16
> > 
> > and see if the 3rd value would make sense as a VID value for your CPU.
> 
> Ah interesting.  It doesn't seem to for me though:
> 
>        0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 0800: ff 01 cf fa f7 07 ff ff ff ff ff ff ff ff ff ff
> 
> VRM v11 (in hwmon-vid) says values can't be > 0xb2, although I don't know how
> many bits are wired up to the VID.
> 
> So is 0x802 the GPIO input?  I wonder what it's wired up to...?

My instructions were for Simon. Unless you have the exact same
motherboard model, chances are high that these instructions do not
apply to you. I'd need the output of:

# isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 7

as Simon already provided, to comment on your case. Just because the
symptoms look similar to Simon's, doesn't mean the problem is the same,
nor that the solution (if there exists any) would be the same.
Although, given the same motherboard manufacturer, there is a remote
chance.

> > One thing we could do is teach the it87 driver to not export the VID
> > value if any of VID pins 0-3 are configured for GPIO function. That
> > wouldn't be too difficult, but would you be able to test a kernel patch?
> 
> I can test an it87 patch if you need a guinea pig - especially if it'll
> compile against 2.6.30 so I don't have to reboot ;-)

Sure, I can provide a standalone driver for any kernel version, no
reboot needed unless I badly screw up ;)

But please provide a dump first.

-- 
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] Gigabyte GA-P35-DS3P - VID Zero value

[Adam Nielsen]

> My instructions were for Simon. Unless you have the exact same
> motherboard model, chances are high that these instructions do not
> apply to you.

I understand, but our two motherboards are merely different revisions.  I
think mine has different onboard audio or something...

> I'd need the output of:
> 
> # isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 7

Ha, well I certainly get different output to Simon:

$ isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 7
WARNING! Running this program can cause system crashes, data loss and worse!
I will probe address register 0x2e and data register 0x2f.
Probing bank 7 using bank register 0x07.
Continue? [Y/n] y
Segmentation fault

Not sure that GDB is much help here:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000401068 in superio_write_key (addrregF, key=<value optimized
out>) at /usr/include/sys/io.h:99
99        __asm__ __volatile__ ("outb %b0,%w1": :"a" (__value), "Nd" (__port));

I stuffed around a bit more with the command arguments and eventually got the
original command to work:

$ isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 7
WARNING! Running this program can cause system crashes, data loss and worse!
I will probe address register 0x2e and data register 0x2f.
Probing bank 7 using bank register 0x07.
Continue? [Y/n]
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 87 18 04 10 00 80 df 3f 43 89 00 00 1d 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 c2 00 00 00 00 00 00
c0: 80 1d 3f 43 09 00 00 00 00 19 00 03 08 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7e
f0: 10 40 00 00 00 00 11 00 00 00 00 00 3f 00 00 00

Looks pretty similar to Simon, so I think we're all good there.

> as Simon already provided, to comment on your case. Just because the
> symptoms look similar to Simon's, doesn't mean the problem is the same,
> nor that the solution (if there exists any) would be the same.
> Although, given the same motherboard manufacturer, there is a remote
> chance.

Yup, like I say, different revisions of the same motherboard.

>>> One thing we could do is teach the it87 driver to not export the VID
>>> value if any of VID pins 0-3 are configured for GPIO function. That
>>> wouldn't be too difficult, but would you be able to test a kernel patch?
>> I can test an it87 patch if you need a guinea pig - especially if it'll
>> compile against 2.6.30 so I don't have to reboot ;-)
> 
> Sure, I can provide a standalone driver for any kernel version, no
> reboot needed unless I badly screw up ;)

Haha yes, of course :-)

Cheers,
Adam.

P.S. Just realised I had sensor programs running while I was running that,
that's probably the reason for the segfault :-$

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

Re: [lm-sensors] Gigabyte GA-P35-DS3P - VID Zero value

[Jean Delvare]

On Tue, 20 Oct 2009 22:15:54 +1000, Adam Nielsen wrote:
> > # isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 7
> 
> Ha, well I certainly get different output to Simon:
> 
> $ isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 7
> WARNING! Running this program can cause system crashes, data loss and worse!
> I will probe address register 0x2e and data register 0x2f.
> Probing bank 7 using bank register 0x07.
> Continue? [Y/n] y
> Segmentation fault
> 
> Not sure that GDB is much help here:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000401068 in superio_write_key (addrregF, key=<value optimized
> out>) at /usr/include/sys/io.h:99
> 99        __asm__ __volatile__ ("outb %b0,%w1": :"a" (__value), "Nd" (__port));
> 
> I stuffed around a bit more with the command arguments and eventually got the
> original command to work:
> 
> $ isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 7
> WARNING! Running this program can cause system crashes, data loss and worse!
> I will probe address register 0x2e and data register 0x2f.
> Probing bank 7 using bank register 0x07.
> Continue? [Y/n]
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00: 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 87 18 04 10 00 80 df 3f 43 89 00 00 1d 00 00 00
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 60: 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00
> 70: 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00
> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> b0: 00 00 00 00 00 00 00 00 00 c2 00 00 00 00 00 00
> c0: 80 1d 3f 43 09 00 00 00 00 19 00 03 08 00 00 00
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7e
> f0: 10 40 00 00 00 00 11 00 00 00 00 00 3f 00 00 00
> 
> Looks pretty similar to Simon, so I think we're all good there.

Indeed, the relevant registers have the same values, so whatever
applies to Simon probably applies to you as well.

> > as Simon already provided, to comment on your case. Just because the
> > symptoms look similar to Simon's, doesn't mean the problem is the same,
> > nor that the solution (if there exists any) would be the same.
> > Although, given the same motherboard manufacturer, there is a remote
> > chance.
> 
> Yup, like I say, different revisions of the same motherboard.
> 
> >>> One thing we could do is teach the it87 driver to not export the VID
> >>> value if any of VID pins 0-3 are configured for GPIO function. That
> >>> wouldn't be too difficult, but would you be able to test a kernel patch?
> >> I can test an it87 patch if you need a guinea pig - especially if it'll
> >> compile against 2.6.30 so I don't have to reboot ;-)
> > 
> > Sure, I can provide a standalone driver for any kernel version, no
> > reboot needed unless I badly screw up ;)
> 
> Haha yes, of course :-)
> 
> Cheers,
> Adam.
> 
> P.S. Just realised I had sensor programs running while I was running that,
> that's probably the reason for the segfault :-$

Shouldn't be, as the it87 driver doesn't access 0x2e/0x2f past
initialization. But other kernel drivers might. As the same command
that crashed, worked some time after, I admit I have no idea what could
have caused the crash.

-- 
Jean Delvare

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

Re: [lm-sensors] Gigabyte GA-P35-DS3P - VID Zero value

[Simon Wilson]

Quoting Jean Delvare <khali@linux-fr.org>:

> Hi Simon,
>
>
> The raw VID value is at 0xfc, value is 0x3f, which means all VID pins
> are high. Which means they are not wired to the CPU, otherwise at least
> one of them would be low.
>
> Now, looking at register 0x27, it appears that all VID input pins have
> been configured for their alternative function (GPIO.) This is not the
> default value for this register, which means that the motherboard
> vendor decided to not use these pins for VID input but for another
> function.
>
> BTW... the pins in question are in input mode. So who knows... maybe
> they ARE used for VID monitoring, and GPIO was preferred over true VID
> for obscure reasons (incompatible voltage levels?) You may want to run,
> as root:
>
> isadump -f 0x800 16

WARNING! Running this program can cause system crashes, data loss and worse!
I will probe address range 0x800 to 0x80f.
Continue? [Y/n] y
        0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
0800: ff 21 cf fa f5 07 ff ff ff ff ff ff ff ff ff ff

>
> and see if the 3rd value would make sense as a VID value for your CPU.

Does it? CF hex = 207 dec... surely not 2.07V?!? According to Intel  
the e6850 should have a VID of 1.3 or 1.35V.

>
> Ask the manufacturer to confirm this, and if they do, blame it on them.

I can ask them in my IT job capacity - they may help... can you help  
me with the gist of what I need to ask them? :)

>
> One thing we could do is teach the it87 driver to not export the VID
> value if any of VID pins 0-3 are configured for GPIO function. That
> wouldn't be too difficult, but would you be able to test a kernel patch?
>

Happy to help - as long as you provide idiot-proof instructions LOL...  
the closest I've ever got to kernel stuff I've ever done is loading  
the kmod drivers, which isn't exactly difficult. Bear in mind I'm  
running a xen kernel:

2.6.18-164.el5xen

I "believe" that in0 actually provides a VCore reading on this setup  
anyway - it varies between 1.04V and 1.2V, which would seem to me to  
be about right. Unless I'm off on the wrong track there too and that  
needs a modifying calcluation for something else.

Thanks for your help Jean, much appreciated. It's not critical, but I  
like having things finished and working well.

Simon
-- 
Simon Wilson
www.simonandkate.net

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

Re: [lm-sensors] Gigabyte GA-P35-DS3P - VID Zero value

[Simon Wilson]

Quoting Jean Delvare <khali@linux-fr.org>:

> Your register dump makes it pretty clear that there is no VID value to
> be read in the first place. At least not from the VID value register
> 0xfc).
>
> --
> Jean Delvare
>
>

What does this mean (taken from the it87.c documentation):

"The IT8718F and IT8720F also features VID inputs (up to 8 pins) but the value
is stored in the Super-I/O configuration space. Due to technical limitations,
this value can currently only be read once at initialization time, so
the driver won't notice and report changes in the VID value. The two
upper VID bits share their pins with voltage inputs (in5 and in6) so you
can't have both on a given board."

and...

   /* The device with the IT8718F/IT8720F VID value in it */
   #define GPIO    0x07

There are a few web pages out there with doco on that file (e.g.  
http://www.lm-sensors.org/attachment/ticket/2343/hwmon-it87-add-it8720f-support.patch).

They seem to refer to that chip holding VID in a different space... am  
I reading that wrongly?  :-D

At the end of the day, from my reading VID is what is used to  
kickstart the CPU, correct? Ongoing V to actually run it is what is  
measured as VCore, and this varies on modern CPUs. So what VID is  
really doesn't matter on a running system - and as it's only read into  
the IT8718F once on boot, reading it with lm_sensors doesn't really  
give me much useful data. Is that a correct(ish) understanding?

Of more real use I guess would be a range that I would expect to see  
at VCore (which I think is what I am seeing at in0), i.e. 1.04V to  
1.25V.

In which case, as you have previously mentioned, telling the IT87  
driver to ignore VID if it doesn't contain anything useful is probably  
the way to go...

Simon.

-- 
Simon Wilson
www.simonandkate.net

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

Re: [lm-sensors] Gigabyte GA-P35-DS3P - VID Zero value

[Jean Delvare]

Hi Simon,

On Wed, 21 Oct 2009 22:15:34 +1000, Simon Wilson wrote:
> Quoting Jean Delvare <khali@linux-fr.org>:
> > The raw VID value is at 0xfc, value is 0x3f, which means all VID pins
> > are high. Which means they are not wired to the CPU, otherwise at least
> > one of them would be low.
> >
> > Now, looking at register 0x27, it appears that all VID input pins have
> > been configured for their alternative function (GPIO.) This is not the
> > default value for this register, which means that the motherboard
> > vendor decided to not use these pins for VID input but for another
> > function.
> >
> > BTW... the pins in question are in input mode. So who knows... maybe
> > they ARE used for VID monitoring, and GPIO was preferred over true VID
> > for obscure reasons (incompatible voltage levels?) You may want to run,
> > as root:
> >
> > isadump -f 0x800 16
> 
> WARNING! Running this program can cause system crashes, data loss and worse!
> I will probe address range 0x800 to 0x80f.
> Continue? [Y/n] y
>         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 0800: ff 21 cf fa f5 07 ff ff ff ff ff ff ff ff ff ff
> 
> >
> > and see if the 3rd value would make sense as a VID value for your CPU.
> 
> Does it? CF hex = 207 dec... surely not 2.07V?!? According to Intel  
> the e6850 should have a VID of 1.3 or 1.35V.

First of all, the upper 2 bits are irrelevant as only 6 GPIO3 pins have
been setup. So the value would be 0x0f. Secondly, decoding VID values
is somewhat more complex than that. You can look at
drivers/hwmon/hwmon-vid.c in the kernel source tree [1], or look on the
Intel developer web site for the VRM/VRD specification which applied to
your CPU model.

For VRM/VRD 11.0, which your CPU seems to use, 0x0f translates to
1.519 V, which is definitely not correct. This leads me to the
conclusion that this isn't a valid VID value.

> > Ask the manufacturer to confirm this, and if they do, blame it on them.
> 
> I can ask them in my IT job capacity - they may help... can you help  
> me with the gist of what I need to ask them? :)

Basically, we want to know:

* What are pins 13-14 and 16-19 of the IT8716F connected to on your
  motherboard: CPU VID or something else.
* If CPU VID, what's the trick (chip configuration steps) to get the
  correct value?

> > One thing we could do is teach the it87 driver to not export the VID
> > value if any of VID pins 0-3 are configured for GPIO function. That
> > wouldn't be too difficult, but would you be able to test a kernel patch?
> 
> Happy to help - as long as you provide idiot-proof instructions LOL...  
> the closest I've ever got to kernel stuff I've ever done is loading  
> the kmod drivers, which isn't exactly difficult. Bear in mind I'm  
> running a xen kernel:
> 
> 2.6.18-164.el5xen
> 
> I "believe" that in0 actually provides a VCore reading on this setup  
> anyway - it varies between 1.04V and 1.2V, which would seem to me to  
> be about right. Unless I'm off on the wrong track there too and that  
> needs a modifying calcluation for something else.

What I need is someone who can build kernel modules. It is possible
that xen will get in our way, and Adam apparently knows more than you
do about building kernel modules, so I think I will ask for his help.

> Thanks for your help Jean, much appreciated. It's not critical, but I  
> like having things finished and working well.

You're welcome. It doesn't look like we're progressing much though :/

-- 
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] Gigabyte GA-P35-DS3P - VID Zero value

[Jean Delvare]

On Tue, 20 Oct 2009 21:50:31 +1000, Adam Nielsen wrote:
> > The raw VID value is at 0xfc, value is 0x3f, which means all VID pins
> > are high. Which means they are not wired to the CPU, otherwise at least
> > one of them would be low.
> > 
> > Now, looking at register 0x27, it appears that all VID input pins have
> > been configured for their alternative function (GPIO.) This is not the
> > default value for this register, which means that the motherboard
> > vendor decided to not use these pins for VID input but for another
> > function.
> > 
> > BTW... the pins in question are in input mode. So who knows... maybe
> > they ARE used for VID monitoring, and GPIO was preferred over true VID
> > for obscure reasons (incompatible voltage levels?) You may want to run,
> > as root:
> > 
> > isadump -f 0x800 16
> > 
> > and see if the 3rd value would make sense as a VID value for your CPU.
> 
> Ah interesting.  It doesn't seem to for me though:
> 
>        0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 0800: ff 01 cf fa f7 07 ff ff ff ff ff ff ff ff ff ff
> 
> VRM v11 (in hwmon-vid) says values can't be > 0xb2, although I don't know how
> many bits are wired up to the VID.
> 
> So is 0x802 the GPIO input?  I wonder what it's wired up to...?

See my answer to Simon. 6 VID bits -> 0x0f -> 1.519 V -> definitely not
the right voltage for your CPU. Dead end.

> > One thing we could do is teach the it87 driver to not export the VID
> > value if any of VID pins 0-3 are configured for GPIO function. That
> > wouldn't be too difficult, but would you be able to test a kernel patch?
> 
> I can test an it87 patch if you need a guinea pig - especially if it'll
> compile against 2.6.30 so I don't have to reboot ;-)

I'll prepare a patch as my time and health permits.

-- 
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] Gigabyte GA-P35-DS3P - VID Zero value

[Simon Wilson]

Quoting Jean Delvare <khali@linux-fr.org>:

> First of all, the upper 2 bits are irrelevant as only 6 GPIO3 pins have
> been setup. So the value would be 0x0f. Secondly, decoding VID values
> is somewhat more complex than that. You can look at
> drivers/hwmon/hwmon-vid.c in the kernel source tree [1], or look on the
> Intel developer web site for the VRM/VRD specification which applied to
> your CPU model.
>
> For VRM/VRD 11.0, which your CPU seems to use, 0x0f translates to
> 1.519 V, which is definitely not correct. This leads me to the
> conclusion that this isn't a valid VID value.
>
> Basically, we want to know:
>
> * What are pins 13-14 and 16-19 of the IT8716F connected to on your
>   motherboard: CPU VID or something else.
> * If CPU VID, what's the trick (chip configuration steps) to get the
>   correct value?
>
> What I need is someone who can build kernel modules. It is possible
> that xen will get in our way, and Adam apparently knows more than you
> do about building kernel modules, so I think I will ask for his help.

Sounds like a plan. Thanks Jean.

> You're welcome. It doesn't look like we're progressing much though :/

Ah progress has many definitions. :)

-- 
Simon Wilson
www.simonandkate.net

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

Re: [lm-sensors] Gigabyte GA-P35-DS3P - VID Zero value

[Jean Delvare]

Hi Simon,

On Wed, 21 Oct 2009 22:30:42 +1000, Simon Wilson wrote:
> What does this mean (taken from the it87.c documentation):
> 
> "The IT8718F and IT8720F also features VID inputs (up to 8 pins) but the value
> is stored in the Super-I/O configuration space. Due to technical limitations,
> this value can currently only be read once at initialization time, so
> the driver won't notice and report changes in the VID value. The two
> upper VID bits share their pins with voltage inputs (in5 and in6) so you
> can't have both on a given board."
> 
> and...
> 
>    /* The device with the IT8718F/IT8720F VID value in it */
>    #define GPIO    0x07
> 
> There are a few web pages out there with doco on that file (e.g.  
> http://www.lm-sensors.org/attachment/ticket/2343/hwmon-it87-add-it8720f-support.patch).
> 
> They seem to refer to that chip holding VID in a different space... am  
> I reading that wrongly?  :-D

You are right. But this was fixed a long time ago. The register dumps
you provided clearly show that the problem is at the hardware level and
not at the driver level.

> At the end of the day, from my reading VID is what is used to  
> kickstart the CPU, correct? Ongoing V to actually run it is what is  
> measured as VCore, and this varies on modern CPUs. So what VID is  
> really doesn't matter on a running system - and as it's only read into  
> the IT8718F once on boot, reading it with lm_sensors doesn't really  
> give me much useful data. Is that a correct(ish) understanding?

Not exactly. You are right that Vcore (in0) measures the actual CPU
voltage at any given time. VID, however, still matters after boot time.
VID is the (encoded) voltage _requested_ by the CPU. Which, as you
know, can vary over time for modern CPUs. So normally Vcore = VID, all
the time, if your power supply unit does its job correctly.

Now you are right that the limitation of the it87 driver to only read
VID at initialization time (for some of the supported chips at least,
amongst which the IT8718F) makes the VID value useless on systems with
CPU changing VID over time, as is your case. Even if we managed to get
a valid VID reading from your IT8718F chip (assuming this is possible
at all) it wouldn't be that interesting, unless we also address the
driver limitation about reading VID in real-time. Which is very complex
(which is why it didn't happen yet.)

> Of more real use I guess would be a range that I would expect to see  
> at VCore (which I think is what I am seeing at in0), i.e. 1.04V to  
> 1.25V.
> 
> In which case, as you have previously mentioned, telling the IT87  
> driver to ignore VID if it doesn't contain anything useful is probably  
> the way to go...

I agree it is probably the best thing you can do, until the it87 driver
is taught to hide invalid VID readings automatically.

-- 
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] Gigabyte GA-P35-DS3P - VID Zero value

[Adam Nielsen]

> Now you are right that the limitation of the it87 driver to only read
> VID at initialization time (for some of the supported chips at least,
> amongst which the IT8718F) makes the VID value useless on systems with
> CPU changing VID over time, as is your case. Even if we managed to get
> a valid VID reading from your IT8718F chip (assuming this is possible
> at all) it wouldn't be that interesting, unless we also address the
> driver limitation about reading VID in real-time. Which is very complex
> (which is why it didn't happen yet.)

Are you suggesting resetting the chip occasionally to read in the VID again?
Because that's an interesting idea...but yes, it would be complicated :-)

Cheers,
Adam.


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

Re: [lm-sensors] Gigabyte GA-P35-DS3P - VID Zero value

[Jean Delvare]

On Wed, 21 Oct 2009 23:28:38 +1000, Adam Nielsen wrote:
> > Now you are right that the limitation of the it87 driver to only read
> > VID at initialization time (for some of the supported chips at least,
> > amongst which the IT8718F) makes the VID value useless on systems with
> > CPU changing VID over time, as is your case. Even if we managed to get
> > a valid VID reading from your IT8718F chip (assuming this is possible
> > at all) it wouldn't be that interesting, unless we also address the
> > driver limitation about reading VID in real-time. Which is very complex
> > (which is why it didn't happen yet.)
> 
> Are you suggesting resetting the chip occasionally to read in the VID again?
> Because that's an interesting idea...but yes, it would be complicated :-)

No, it's not a problem of resetting the chip. The problem is that the
VID reading is in shared registers, which other drivers may access too.
So we need proper locking to protect the access to these registers.
This requires cooperation between the drivers. There have been some
efforts related to this, but we're not there yet.

For now we're working around the problem by only accessing the
registers at module load time, because the kernel serializes module
loading. But this is a hack, really.

-- 
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] Gigabyte GA-P35-DS3P - VID Zero value

[Jean Delvare]

Hi Adam,

On Wed, 21 Oct 2009 14:53:19 +0200, Jean Delvare wrote:
> On Tue, 20 Oct 2009 21:50:31 +1000, Adam Nielsen wrote:
> > I can test an it87 patch if you need a guinea pig - especially if it'll
> > compile against 2.6.30 so I don't have to reboot ;-)
> 
> I'll prepare a patch as my time and health permits.

Here's a standalone driver for you to try:
http://khali.linux-fr.org/devel/misc/it87/

Build with "make", then as root, "rmmod it87 && insmod it87.ko".

Should build fine on any recent kernel. Fixes in this version of the
it87 driver:
* Really read VID on IT8718F/IT8720F.
* Don't expose VID if pins are in GPIO mode.
* Don't expose fan2 if pin is in GPIO mode.
* Don't expose fan3 if pin is in GPIO mode.
* Don't expose pwm2 if pin is in GPIO mode.
* Don't expose pwm3 if pin is in GPIO mode.

According to the dump you sent, only item #2 should be relevant for
your motherboard.

The last 5 items affect all chip types except the IT8705F. Everyone
else with one of the affected chips is welcome to test and report.

I'll send separate patches to the mailing list soon, for review.

-- 
Jean Delvare

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

Re: [lm-sensors] Gigabyte GA-P35-DS3P - VID Zero value

[Adam Nielsen]

> Here's a standalone driver for you to try:
> http://khali.linux-fr.org/devel/misc/it87/
>
> Build with "make", then as root, "rmmod it87&&  insmod it87.ko".

Works fine!  The "cpu0_vid" and "vrm" files disappear from the it87 sysfs 
directory, and 'sensors' no longer reports a value for the VID.  There is a 
log message telling me in3 is VCC (+5V), but no log message to tell me the VID 
is disabled.  Not sure if that's worth including, in case somebody is trying 
to figure out why their it87 behaves differently to someone else's.

Everything else seems to work as before.

Cheers,
Adam.

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

Re: [lm-sensors] Gigabyte GA-P35-DS3P - VID Zero value

[Jean Delvare]

Hi Adam,

On Fri, 23 Oct 2009 09:20:37 +1000, Adam Nielsen wrote:
> > Here's a standalone driver for you to try:
> > http://khali.linux-fr.org/devel/misc/it87/
> >
> > Build with "make", then as root, "rmmod it87&&  insmod it87.ko".
> 
> Works fine!  The "cpu0_vid" and "vrm" files disappear from the it87 sysfs 
> directory, and 'sensors' no longer reports a value for the VID.  There is a 
> log message telling me in3 is VCC (+5V), but no log message to tell me the VID 
> is disabled.  Not sure if that's worth including, in case somebody is trying 
> to figure out why their it87 behaves differently to someone else's.

I have been considering it. In general drivers should be quiet when
everything works fine. But indeed this is a change in behavior, which
might be worth underlining in the log. I'll add a message.

> Everything else seems to work as before.

Great, thanks for testing and reporting!

-- 
Jean Delvare

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