* Re: [lm-sensors] hwmon-vid driver from linux 2.6.29
2009-05-14 19:07 [lm-sensors] hwmon-vid driver from linux 2.6.29 Rudolf Marek
@ 2009-05-14 19:14 ` Hleb Valoshka
2009-06-05 15:12 ` Jean Delvare
` (12 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: Hleb Valoshka @ 2009-05-14 19:14 UTC (permalink / raw)
To: lm-sensors
eax in eax ebx ecx edx
00000000 00000001 68747541 444d4163 69746e65
00000001 00060fb1 01020800 00002001 178bfbff
80000000 80000018 68747541 444d4163 69746e65
80000001 00060fb1 0000464a 0000011f ebd3fbff
80000002 20444d41 6c687441 74286e6f 5820296d
80000003 75442032 43206c61 2065726f 636f7250
80000004 6f737365 45422072 3533322d 00000030
80000005 ff08ff08 ff20ff20 40020140 40020140
80000006 00000000 42004200 02008140 00000000
80000007 00000000 00000000 00000000 0000007f
80000008 00003028 00000000 00000001 00000000
80000009 00000000 00000000 00000000 00000000
8000000a 00000001 00000040 00000000 00000002
8000000b 00000000 00000000 00000000 00000000
8000000c 00000000 00000000 00000000 00000000
8000000d 00000000 00000000 00000000 00000000
8000000e 00000000 00000000 00000000 00000000
8000000f 00000000 00000000 00000000 00000000
80000010 00000000 00000000 00000000 00000000
80000011 00000000 00000000 00000000 00000000
80000012 00000000 00000000 00000000 00000000
80000013 00000000 00000000 00000000 00000000
80000014 00000000 00000000 00000000 00000000
80000015 00000000 00000000 00000000 00000000
80000016 00000000 00000000 00000000 00000000
80000017 00000000 00000000 00000000 00000000
80000018 00000000 00000000 00000000 00000000
Vendor ID: "AuthenticAMD"; CPUID level 1
AMD-specific functions
Version 00060fb1:
Family: 15 Model: 11 []
Standard feature flags 178bfbff:
Floating Point Unit
Virtual Mode Extensions
Debugging Extensions
Page Size Extensions
Time Stamp Counter (with RDTSC and CR4 disable bit)
Model Specific Registers with RDMSR & WRMSR
PAE - Page Address Extensions
Machine Check Exception
COMPXCHG8B Instruction
APIC
SYSCALL/SYSRET or SYSENTER/SYSEXIT instructions
MTRR - Memory Type Range Registers
Global paging extension
Machine Check Architecture
Conditional Move Instruction
PAT - Page Attribute Table
PSE-36 - Page Size Extensions
19 - reserved
MMX instructions
FXSAVE/FXRSTOR
25 - reserved
26 - reserved
28 - reserved
Generation: 15 Model: 11
Extended feature flags ebd3fbff:
Floating Point Unit
Virtual Mode Extensions
Debugging Extensions
Page Size Extensions
Time Stamp Counter (with RDTSC and CR4 disable bit)
Model Specific Registers with RDMSR & WRMSR
PAE - Page Address Extensions
Machine Check Exception
COMPXCHG8B Instruction
APIC
SYSCALL/SYSRET or SYSENTER/SYSEXIT instructions
MTRR - Memory Type Range Registers
Global paging extension
Machine Check Architecture
Conditional Move Instruction
PAT - Page Attribute Table
PSE-36 - Page Size Extensions
20 - reserved
AMD MMX Instruction Extensions
MMX instructions
FXSAVE/FXRSTOR
25 - reserved
27 - reserved
29 - reserved
3DNow! Instruction Extensions
3DNow instructions
Processor name string: AMD Athlon(tm) X2 Dual Core Processor BE-2350
L1 Cache Information:
2/4-MB Pages:
Data TLB: associativity 255-way #entries 8
Instruction TLB: associativity 255-way #entries 8
4-KB Pages:
Data TLB: associativity 255-way #entries 32
Instruction TLB: associativity 255-way #entries 32
L1 Data cache:
size 64 KB associativity 2-way lines per tag 1 line size 64
L1 Instruction cache:
size 64 KB associativity 2-way lines per tag 1 line size 64
L2 Cache Information:
2/4-MB Pages:
Data TLB: associativity L2 off #entries 0
Instruction TLB: associativity L2 off #entries 0
4-KB Pages:
Data TLB: associativity 2-way #entries 0
Instruction TLB: associativity 2-way #entries 0
size 2 KB associativity L2 off lines per tag 129 line size 64
Advanced Power Management Feature Flags
Has temperature sensing diode
Supports Frequency ID control
Supports Voltage ID control
Maximum linear address: 48; maximum phys address 40
On 5/14/09, Rudolf Marek <r.marek@assembler.cz> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
>
>
> I'm posting this to mailing list. I did no changes a long time. I need to
> check
> that. In the meanwhile can you give me an output of "cpuid" utility.
>
> Thanks,
> Rudolf
>
>
>
>
>
> Gnu Belarusian wrote:
>> Hallo!
>>
>> Module hwmon_vid (drivers/hwmon/hwmon-vid.c) from linux-2.6.29(.3) returns
>>
>> incorrect voltage for my CPU from it8716f sensor (real/2).
>> With module from 2.6.26 voltage is correct.
>>
>> Code changed between versions:
>>
>> int vid_from_reg(int val, u8 vrm)
>> {
>> int vid;
>> @@ -96,9 +102,16 @@
>> if (val < 0x02 || val > 0xb2)
>> return 0;
>> return((1600000 - (val - 2) * 6250 + 500) / 1000);
>> - case 24: /* Opteron processor */
>> +
>> + case 24: /* Athlon64 & Opteron */
>> val &= 0x1f;
>> - return(val = 0x1f ? 0 : 1550 - val * 25);
>> + if (val = 0x1f)
>> + return 0;
>> + /* fall through */
>> + case 25: /* AMD NPT 0Fh */
>> + val &= 0x3f;
>> + return (val < 32) ? 1550 - 25 * val
>> + : 775 - (25 * (val - 31)) / 2;
>>
>> May be you should revert old code.
>>
>> My CPU is AMD BE-2350 stepping 01. IT87 sensor: IT8716F chip at 0x228,
>> revision 0.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkoMa/QACgkQ3J9wPJqZRNWzWwCfco9A7j9dMJhVoeFaHcgS6QSp
> vmkAn2l+5gDcPnsSbsa7/AKCpbLCtM/I
> =pf/j
> -----END PGP SIGNATURE-----
>
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [lm-sensors] hwmon-vid driver from linux 2.6.29
2009-05-14 19:07 [lm-sensors] hwmon-vid driver from linux 2.6.29 Rudolf Marek
2009-05-14 19:14 ` Hleb Valoshka
@ 2009-06-05 15:12 ` Jean Delvare
2009-06-06 14:31 ` Hleb Valoshka
` (11 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: Jean Delvare @ 2009-06-05 15:12 UTC (permalink / raw)
To: lm-sensors
Hi Hleb,
On Thu, 14 May 2009 22:14:36 +0300, Hleb Valoshka wrote:
> Vendor ID: "AuthenticAMD"; CPUID level 1
>
> AMD-specific functions
> Version 00060fb1:
> Family: 15 Model: 11 []
This is a BH-G1 core, family 0Fh, it does have 6 VID pins, so VRM
version "25" (in hwmon-vid's terms) is correct. Is it the value
returned in /sys/bus/platform/devices/it87.552/vrm? I suppose the value
returned in that file in kernel 2.6.26 was "24" instead?
> >> Module hwmon_vid (drivers/hwmon/hwmon-vid.c) from linux-2.6.29(.3) returns
> >>
> >> incorrect voltage for my CPU from it8716f sensor (real/2).
> >> With module from 2.6.26 voltage is correct.
What was the voltage value before, and what is it now?
> >> Code changed between versions:
> >>
> >> int vid_from_reg(int val, u8 vrm)
> >> {
> >> int vid;
> >> @@ -96,9 +102,16 @@
> >> if (val < 0x02 || val > 0xb2)
> >> return 0;
> >> return((1600000 - (val - 2) * 6250 + 500) / 1000);
> >> - case 24: /* Opteron processor */
> >> +
> >> + case 24: /* Athlon64 & Opteron */
> >> val &= 0x1f;
> >> - return(val = 0x1f ? 0 : 1550 - val * 25);
> >> + if (val = 0x1f)
> >> + return 0;
> >> + /* fall through */
> >> + case 25: /* AMD NPT 0Fh */
> >> + val &= 0x3f;
> >> + return (val < 32) ? 1550 - 25 * val
> >> + : 775 - (25 * (val - 31)) / 2;
> >>
> >> May be you should revert old code.
> >>
> >> My CPU is AMD BE-2350 stepping 01. IT87 sensor: IT8716F chip at 0x228,
> >> revision 0.
The hwmon-vid code looks correct, and I think you are the first person
complaining since the code was changed (while we did have success
reports.) It could be that VID5 pin is not properly wired on your
system. Or a bug in the it87 driver.
Please provide a dump of your IT8716F chip:
isadump 0x22d 0x22e
As well as a dump of the Super-I/O config space:
isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 4
Also, if you use the powernow-k8 driver, it should print the available
VIDs when the driver is loaded, please report what the driver says.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [lm-sensors] hwmon-vid driver from linux 2.6.29
2009-05-14 19:07 [lm-sensors] hwmon-vid driver from linux 2.6.29 Rudolf Marek
2009-05-14 19:14 ` Hleb Valoshka
2009-06-05 15:12 ` Jean Delvare
@ 2009-06-06 14:31 ` Hleb Valoshka
2009-06-08 12:11 ` Jean Delvare
` (10 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: Hleb Valoshka @ 2009-06-06 14:31 UTC (permalink / raw)
To: lm-sensors
On 6/5/09, Jean Delvare <khali@linux-fr.org> wrote:
>> AMD-specific functions
>> Version 00060fb1:
>> Family: 15 Model: 11 []
> This is a BH-G1 core, family 0Fh, it does have 6 VID pins, so VRM
> version "25" (in hwmon-vid's terms) is correct. Is it the value
> returned in /sys/bus/platform/devices/it87.552/vrm? I suppose the value
> returned in that file in kernel 2.6.26 was "24" instead?
@globus-debian:~$ cat /sys/bus/platform/devices/it87.552/vrm
25
yes, with 2.6.26 it was 24
>> >> Module hwmon_vid (drivers/hwmon/hwmon-vid.c) from linux-2.6.29(.3)
>> >> returns
>> >>
>> >> incorrect voltage for my CPU from it8716f sensor (real/2).
>> >> With module from 2.6.26 voltage is correct.
> What was the voltage value before, and what is it now?
cpu freq | 2.6.26 | 2.6.29
---------------------------------
1 GHz | 1.1 V | 0.54 V
2.1 GHz | 1.25 V | 0,61 V
> The hwmon-vid code looks correct, and I think you are the first person
> complaining since the code was changed (while we did have success
> reports.) It could be that VID5 pin is not properly wired on your
> system. Or a bug in the it87 driver.
Is it wired on motherboard? It's Gigabyte GA-MA69VM-S2 (amd rs690v based)
> Please provide a dump of your IT8716F chip:
>
> isadump 0x22d 0x22e
@globus-debian:~$ sudo isadump 0x22d 0x22e
WARNING! Running this program can cause system crashes, data loss and worse!
I will probe address register 0x22d and data register 0x22e.
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 11 10 00 00 ff ff 00 37 ff 87 32 09 07 11 ff 00
10: ff ff ff 31 d7 82 7f c2 02 ff 00 ff ff ff ff ff
20: 44 79 d2 bb c3 ca 46 b8 be 29 20 16 7e 8d 8d 8d
30: ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00
40: 7f 7f 7f 7f 7f 7f 00 0d 2d ff ff ff ff ff ff ff
50: ff 1c 7f 7f 7f 50 eb eb 90 eb 00 12 60 00 00 00
60: ff 14 7f 27 90 03 ff ff 7f 7f 7f 00 00 7f ff ff
70: ff 14 7f 20 90 03 ff ff ff ff ff ff ff ff ff ff
80: 00 00 00 00 ff ff ff ff 00 00 ff c0 02 00 99 99
90: 7f 7f 7f 00 00 7f ff ff 7f 7f 7f 00 00 7f ff ff
a0: 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> As well as a dump of the Super-I/O config space:
> isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 4
@globus-debian:~$ sudo isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 4
WARNING! Running this program can cause system crashes, data loss and worse!
I will probe address register 0x2e and data register 0x2f.
Probing bank 4 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 04 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 16 00 10 1a 00 00 00 80 00 00 00 1f 00 00 00
30: 01 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: 02 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 02 00 00 04 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 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 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 00
f0: 80 00 0e 00 88 00 ff 00 00 00 00 00 00 00 00 00
> Also, if you use the powernow-k8 driver, it should print the available
> VIDs when the driver is loaded, please report what the driver says.
powernow-k8: Found 1 AMD Athlon(tm) X2 Dual Core Processor BE-2350
processors (2 cpu cores) (version 2.20.00)
powernow-k8: 0 : fid 0xd (2100 MHz), vid 0xc
powernow-k8: 1 : fid 0xc (2000 MHz), vid 0xd
powernow-k8: 2 : fid 0xa (1800 MHz), vid 0xf
powernow-k8: 3 : fid 0x2 (1000 MHz), vid 0x12
(To make test I compiled hwmod-vid from 26 for 29 and everything was ok)
--
http://375gnu.wordpress.com
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [lm-sensors] hwmon-vid driver from linux 2.6.29
2009-05-14 19:07 [lm-sensors] hwmon-vid driver from linux 2.6.29 Rudolf Marek
` (2 preceding siblings ...)
2009-06-06 14:31 ` Hleb Valoshka
@ 2009-06-08 12:11 ` Jean Delvare
2009-06-08 14:05 ` Frank Myhr
` (9 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: Jean Delvare @ 2009-06-08 12:11 UTC (permalink / raw)
To: lm-sensors
Hi Hleb,
On Sat, 6 Jun 2009 17:31:31 +0300, Hleb Valoshka wrote:
> On 6/5/09, Jean Delvare <khali@linux-fr.org> wrote:
>
> >> AMD-specific functions
> >> Version 00060fb1:
> >> Family: 15 Model: 11 []
> > This is a BH-G1 core, family 0Fh, it does have 6 VID pins, so VRM
> > version "25" (in hwmon-vid's terms) is correct. Is it the value
> > returned in /sys/bus/platform/devices/it87.552/vrm? I suppose the value
> > returned in that file in kernel 2.6.26 was "24" instead?
>
> @globus-debian:~$ cat /sys/bus/platform/devices/it87.552/vrm
> 25
>
> yes, with 2.6.26 it was 24
>
>
> >> >> Module hwmon_vid (drivers/hwmon/hwmon-vid.c) from linux-2.6.29(.3)
> >> >> returns
> >> >>
> >> >> incorrect voltage for my CPU from it8716f sensor (real/2).
> >> >> With module from 2.6.26 voltage is correct.
> > What was the voltage value before, and what is it now?
>
> cpu freq | 2.6.26 | 2.6.29
> ---------------------------------
> 1 GHz | 1.1 V | 0.54 V
> 2.1 GHz | 1.25 V | 0,61 V
1.25 V is definitely correct and 0.61 V definitely not...
> > The hwmon-vid code looks correct, and I think you are the first person
> > complaining since the code was changed (while we did have success
> > reports.) It could be that VID5 pin is not properly wired on your
> > system. Or a bug in the it87 driver.
>
> Is it wired on motherboard? It's Gigabyte GA-MA69VM-S2 (amd rs690v based)
Yes it is (or should be) wired on the motherboard. Basically, the CPU
has 6 VID (output) pins which should be routed to 6 input pins of the
IT8716F chip. The logical level of these pins is then used by the it87
and hwmon-vid drivers to tell the nominal CPU core voltage.
> > Please provide a dump of your IT8716F chip:
> >
> > isadump 0x22d 0x22e
>
> @globus-debian:~$ sudo isadump 0x22d 0x22e
> WARNING! Running this program can cause system crashes, data loss and worse!
> I will probe address register 0x22d and data register 0x22e.
> Continue? [Y/n] y
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00: 11 10 00 00 ff ff 00 37 ff 87 32 09 07 11 ff 00
VID value is in register 0x0a. Value 0x32 is 110010 binary (0.54 V.)
Kernel 2.6.26 ignored the MSb so it decoded 0x12 -> 1.1 V, which
happened to be correct.
> 10: ff ff ff 31 d7 82 7f c2 02 ff 00 ff ff ff ff ff
> 20: 44 79 d2 bb c3 ca 46 b8 be 29 20 16 7e 8d 8d 8d
> 30: ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00
> 40: 7f 7f 7f 7f 7f 7f 00 0d 2d ff ff ff ff ff ff ff
> 50: ff 1c 7f 7f 7f 50 eb eb 90 eb 00 12 60 00 00 00
> 60: ff 14 7f 27 90 03 ff ff 7f 7f 7f 00 00 7f ff ff
> 70: ff 14 7f 20 90 03 ff ff ff ff ff ff ff ff ff ff
> 80: 00 00 00 00 ff ff ff ff 00 00 ff c0 02 00 99 99
> 90: 7f 7f 7f 00 00 7f ff ff 7f 7f 7f 00 00 7f ff ff
> a0: 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff
> b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>
> > As well as a dump of the Super-I/O config space:
> > isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 4
>
> @globus-debian:~$ sudo isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 4
> WARNING! Running this program can cause system crashes, data loss and worse!
> I will probe address register 0x2e and data register 0x2f.
> Probing bank 4 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 04 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 16 00 10 1a 00 00 00 80 00 00 00 1f 00 00 00
VID input configuration looks OK, all 6 pins are configured for VID
input.
> 30: 01 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: 02 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 70: 00 02 00 00 04 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 00 00 00 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 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 00
> f0: 80 00 0e 00 88 00 ff 00 00 00 00 00 00 00 00 00
For completeness, please also provide the output of:
isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 7
And also tell me which revision is printed when you load the it87
driver.
>
> > Also, if you use the powernow-k8 driver, it should print the available
> > VIDs when the driver is loaded, please report what the driver says.
>
> powernow-k8: Found 1 AMD Athlon(tm) X2 Dual Core Processor BE-2350
> processors (2 cpu cores) (version 2.20.00)
> powernow-k8: 0 : fid 0xd (2100 MHz), vid 0xc
> powernow-k8: 1 : fid 0xc (2000 MHz), vid 0xd
> powernow-k8: 2 : fid 0xa (1800 MHz), vid 0xf
> powernow-k8: 3 : fid 0x2 (1000 MHz), vid 0x12
>
> (To make test I compiled hwmod-vid from 26 for 29 and everything was ok)
So powernow-k8 agrees that VID5 should always be 0 on your CPU.
To me it looks like wiring of VID5 on your motherboard is incorrect,
and it is always set even when the CPU says it should not. In kernel
2.6.26, hwmon-vid was working by accident, and fixing the code made the
problem appear in your case.
You could contact the motherboard vendor and tell them about the
problem (the question is "Is VID5 properly routed from CPU to
IT8716F?") and see what they have to say about this.
I don't really know how to work around this. I suspect that only the
late 0Fh family CPUs actually make use of VID5. If I am right then we
could tweak the hwmon-vid VRM selection table and use 5-pin VID (VRM
code 24) for some of the 0Fh family CPUs. I don't know where to put the
limit, and this is fixing the problem where it is not... which is
likely to cause even more problems on other systems in the future.
Frank, can you please tell us for which 0Fh family CPU model you did
need the 6th VID pin decoding originally?
Maybe we can have a DMI-based workaround either in it87 or hwmon-vid.
This is ugly and we avoid it as much as possible, but if there's no
other way... Hleb, please provide the output of dmidecode on your
system.
In the meantime you can write "24"
to /sys/bus/platform/devices/it87.552/vrm at system boot time, so that
the value of VID5 is ignored (actually forced to 0.)
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [lm-sensors] hwmon-vid driver from linux 2.6.29
2009-05-14 19:07 [lm-sensors] hwmon-vid driver from linux 2.6.29 Rudolf Marek
` (3 preceding siblings ...)
2009-06-08 12:11 ` Jean Delvare
@ 2009-06-08 14:05 ` Frank Myhr
2009-06-08 14:59 ` Jean Delvare
` (8 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: Frank Myhr @ 2009-06-08 14:05 UTC (permalink / raw)
To: lm-sensors
Jean Delvare wrote:
> You could contact the motherboard vendor and tell them about the
> problem (the question is "Is VID5 properly routed from CPU to
> IT8716F?") and see what they have to say about this.
>
> I don't really know how to work around this. I suspect that only the
> late 0Fh family CPUs actually make use of VID5. If I am right then we
> could tweak the hwmon-vid VRM selection table and use 5-pin VID (VRM
> code 24) for some of the 0Fh family CPUs. I don't know where to put the
> limit, and this is fixing the problem where it is not... which is
> likely to cause even more problems on other systems in the future.
>
> Frank, can you please tell us for which 0Fh family CPU model you did
> need the 6th VID pin decoding originally?
Hi Jean and others,
I'm sorry, that system is currently offline and I (not so) cleverly
didn't back up log files so I don't have kernel-reported cpu info. But
here is hardware spec:
cpu: AMD Athlon X2 64 4850e, ADH4850IAA5DO
mainboard: Gigabyte GA-MA770-DS3, IT8718
-Frank
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [lm-sensors] hwmon-vid driver from linux 2.6.29
2009-05-14 19:07 [lm-sensors] hwmon-vid driver from linux 2.6.29 Rudolf Marek
` (4 preceding siblings ...)
2009-06-08 14:05 ` Frank Myhr
@ 2009-06-08 14:59 ` Jean Delvare
2009-06-08 15:28 ` Frank Myhr
` (7 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: Jean Delvare @ 2009-06-08 14:59 UTC (permalink / raw)
To: lm-sensors
On Mon, 08 Jun 2009 10:05:08 -0400, Frank Myhr wrote:
> Jean Delvare wrote:
> > You could contact the motherboard vendor and tell them about the
> > problem (the question is "Is VID5 properly routed from CPU to
> > IT8716F?") and see what they have to say about this.
> >
> > I don't really know how to work around this. I suspect that only the
> > late 0Fh family CPUs actually make use of VID5. If I am right then we
> > could tweak the hwmon-vid VRM selection table and use 5-pin VID (VRM
> > code 24) for some of the 0Fh family CPUs. I don't know where to put the
> > limit, and this is fixing the problem where it is not... which is
> > likely to cause even more problems on other systems in the future.
> >
> > Frank, can you please tell us for which 0Fh family CPU model you did
> > need the 6th VID pin decoding originally?
>
> Hi Jean and others,
>
> I'm sorry, that system is currently offline and I (not so) cleverly
> didn't back up log files so I don't have kernel-reported cpu info. But
> here is hardware spec:
>
> cpu: AMD Athlon X2 64 4850e, ADH4850IAA5DO
> mainboard: Gigabyte GA-MA770-DS3, IT8718
Mmm, this is strange. This CPU should operate at 1.1 to 1.25 V just
like Hleb's. For this range the 5-bit VID codes are sufficient (VRM
code 24 in hwmon-vid). Thus it shouldn't have made a difference when
you added support for 6-bit VID codes. Do you remember why you wrote
that patch in the first place?
Actually I am not aware of _any_ 0Fh family CPU model running at a core
voltage below 0.9 V. This makes me wonder if we shouldn't simply map
the 0Fh family to 5-bit VID decoding and be done with it. This would
avoid potential issues such as the one Hleb is hitting (although I
don't disagree this appears to be a mainboard wiring issue in the first
place.)
Opinions?
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [lm-sensors] hwmon-vid driver from linux 2.6.29
2009-05-14 19:07 [lm-sensors] hwmon-vid driver from linux 2.6.29 Rudolf Marek
` (5 preceding siblings ...)
2009-06-08 14:59 ` Jean Delvare
@ 2009-06-08 15:28 ` Frank Myhr
2009-06-08 15:42 ` Jean Delvare
` (6 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: Frank Myhr @ 2009-06-08 15:28 UTC (permalink / raw)
To: lm-sensors
Jean Delvare wrote:
> On Mon, 08 Jun 2009 10:05:08 -0400, Frank Myhr wrote:
>> Jean Delvare wrote:
>>> You could contact the motherboard vendor and tell them about the
>>> problem (the question is "Is VID5 properly routed from CPU to
>>> IT8716F?") and see what they have to say about this.
>>>
>>> I don't really know how to work around this. I suspect that only the
>>> late 0Fh family CPUs actually make use of VID5. If I am right then we
>>> could tweak the hwmon-vid VRM selection table and use 5-pin VID (VRM
>>> code 24) for some of the 0Fh family CPUs. I don't know where to put the
>>> limit, and this is fixing the problem where it is not... which is
>>> likely to cause even more problems on other systems in the future.
>>>
>>> Frank, can you please tell us for which 0Fh family CPU model you did
>>> need the 6th VID pin decoding originally?
>> Hi Jean and others,
>>
>> I'm sorry, that system is currently offline and I (not so) cleverly
>> didn't back up log files so I don't have kernel-reported cpu info. But
>> here is hardware spec:
>>
>> cpu: AMD Athlon X2 64 4850e, ADH4850IAA5DO
>> mainboard: Gigabyte GA-MA770-DS3, IT8718
>
> Mmm, this is strange. This CPU should operate at 1.1 to 1.25 V just
> like Hleb's. For this range the 5-bit VID codes are sufficient (VRM
> code 24 in hwmon-vid). Thus it shouldn't have made a difference when
> you added support for 6-bit VID codes. Do you remember why you wrote
> that patch in the first place?
I dimly recall that it87 was reporting my cpu voltage incorrectly. In
the course of investigating that I saw AMD 32559 Table 71 and decided to
update hwmon-vid to match it.
I think I continued to have sporadic problems with incorrect VID being
reported after making the change. And in any case, I wasn't using
voltages in the range that would have required 6-bit VID decoding (see
below).
> Actually I am not aware of _any_ 0Fh family CPU model running at a core
> voltage below 0.9 V. This makes me wonder if we shouldn't simply map
> the 0Fh family to 5-bit VID decoding and be done with it. This would
> avoid potential issues such as the one Hleb is hitting (although I
> don't disagree this appears to be a mainboard wiring issue in the first
> place.)
>
> Opinions?
I was undervolting the cpu, but still limited to 0.8V or above by BIOS.
No objection here to go back to 5-bit VID decoding.
Sorry for the problems my patch apparently created :-(
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [lm-sensors] hwmon-vid driver from linux 2.6.29
2009-05-14 19:07 [lm-sensors] hwmon-vid driver from linux 2.6.29 Rudolf Marek
` (6 preceding siblings ...)
2009-06-08 15:28 ` Frank Myhr
@ 2009-06-08 15:42 ` Jean Delvare
2009-06-08 18:03 ` Hleb Valoshka
` (5 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: Jean Delvare @ 2009-06-08 15:42 UTC (permalink / raw)
To: lm-sensors
On Mon, 08 Jun 2009 11:28:49 -0400, Frank Myhr wrote:
> Sorry for the problems my patch apparently created :-(
Don't be, it was technically correct. It's just the real world around
which isn't ;)
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [lm-sensors] hwmon-vid driver from linux 2.6.29
2009-05-14 19:07 [lm-sensors] hwmon-vid driver from linux 2.6.29 Rudolf Marek
` (7 preceding siblings ...)
2009-06-08 15:42 ` Jean Delvare
@ 2009-06-08 18:03 ` Hleb Valoshka
2009-06-08 18:19 ` Jean Delvare
` (4 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: Hleb Valoshka @ 2009-06-08 18:03 UTC (permalink / raw)
To: lm-sensors
[-- Attachment #1: Type: text/plain, Size: 2480 bytes --]
On 6/8/09, Jean Delvare <khali@linux-fr.org> wrote:
> For completeness, please also provide the output of:
> isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 7
su@globus-debian:~$ sudo isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 7
[sudo] password for globus:
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 16 00 10 1a 00 00 00 80 00 00 00 1f 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 02 20 02 38 00 00 00 00 00 00 00 00 00 00
70: 00 01 00 38 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 00 00 80 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 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 00
f0: 00 00 00 00 00 00 27 00 00 00 00 00 32 00 00 00
> And also tell me which revision is printed when you load the it87
> driver.
it87: Found IT8716F chip at 0x228, revision 0
it87: in3 is VCC (+5V)
it87: in7 is VCCH (+5V Stand-By)
> You could contact the motherboard vendor and tell them about the
> problem (the question is "Is VID5 properly routed from CPU to
> IT8716F?") and see what they have to say about this.
The question is sent.
> I don't really know how to work around this. I suspect that only the
> late 0Fh family CPUs actually make use of VID5. If I am right then we
> could tweak the hwmon-vid VRM selection table and use 5-pin VID (VRM
> code 24) for some of the 0Fh family CPUs. I don't know where to put the
> limit, and this is fixing the problem where it is not... which is
> likely to cause even more problems on other systems in the future.
AFAIR my CPU is based on early revisions of Brisban core.
> Maybe we can have a DMI-based workaround either in it87 or hwmon-vid.
> This is ugly and we avoid it as much as possible, but if there's no
> other way... Hleb, please provide the output of dmidecode on your
> system.
It's in attachment
--
http://375gnu.wordpress.com
[-- Attachment #2: file --]
[-- Type: application/octet-stream, Size: 17928 bytes --]
# dmidecode 2.9
SMBIOS 2.4 present.
53 structures occupying 2380 bytes.
Table at 0x000F0100.
Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: Award Software International, Inc.
Version: F8
Release Date: 03/03/2008
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 512 kB
Characteristics:
ISA is supported
PCI is supported
PNP is supported
APM is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/360 KB floppy services are supported (int 13h)
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 KB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
AGP is supported
LS-120 boot is supported
ATAPI Zip drive boot is supported
BIOS boot specification is supported
Targeted content distribution is supported
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: GA-MA69VM-S2
Version:
Serial Number:
UUID: 4E2F4100-0000-0000-0000-0000FFFFFFFF
Wake-up Type: Power Switch
SKU Number:
Family:
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: GA-MA69VM-S2
Version:
Serial Number:
Handle 0x0003, DMI type 3, 17 bytes
Chassis Information
Manufacturer: Gigabyte Technology Co., Ltd.
Type: Desktop
Lock: Not Present
Version:
Serial Number:
Asset Tag:
Boot-up State: Unknown
Power Supply State: Unknown
Thermal State: Unknown
Security Status: Unknown
OEM Information: 0x00000000
Handle 0x0004, DMI type 4, 35 bytes
Processor Information
Socket Designation: Socket M2
Type: Central Processor
Family: Athlon
Manufacturer: AMD
ID: B1 0F 06 00 FF FB 8B 17
Signature: Family 15, Model 107, Stepping 1
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported)
PAT (Page attribute table)
PSE-36 (36-bit page size extension)
CLFSH (CLFLUSH instruction supported)
MMX (MMX technology supported)
FXSR (Fast floating-point save and restore)
SSE (Streaming SIMD extensions)
SSE2 (Streaming SIMD extensions 2)
HTT (Hyper-threading technology)
Version: AMD Athlon(tm) X2 Dual Core Processor BE-2350
Voltage: 1.3 V
External Clock: 200 MHz
Max Speed: 3200 MHz
Current Speed: 2100 MHz
Status: Populated, Enabled
Upgrade: ZIF Socket
L1 Cache Handle: 0x000A
L2 Cache Handle: 0x000C
L3 Cache Handle: Not Provided
Serial Number:
Asset Tag:
Part Number:
Handle 0x0005, DMI type 5, 24 bytes
Memory Controller Information
Error Detecting Method: 64-bit ECC
Error Correcting Capabilities:
None
Supported Interleave: One-way Interleave
Current Interleave: One-way Interleave
Maximum Memory Module Size: 1024 MB
Maximum Total Memory Size: 4096 MB
Supported Speeds:
70 ns
60 ns
Supported Memory Types:
Standard
EDO
Memory Module Voltage: 3.3 V
Associated Memory Slots: 4
0x0006
0x0007
0x0008
0x0009
Enabled Error Correcting Capabilities:
None
Handle 0x0006, DMI type 6, 12 bytes
Memory Module Information
Socket Designation: A0
Bank Connections: 1
Current Speed: 32 ns
Type: Other Unknown EDO
Installed Size: 512 MB (Single-bank Connection)
Enabled Size: 512 MB (Single-bank Connection)
Error Status: OK
Handle 0x0007, DMI type 6, 12 bytes
Memory Module Information
Socket Designation: A1
Bank Connections: 2
Current Speed: 32 ns
Type: Other Unknown EDO
Installed Size: 512 MB (Single-bank Connection)
Enabled Size: 512 MB (Single-bank Connection)
Error Status: OK
Handle 0x0008, DMI type 6, 12 bytes
Memory Module Information
Socket Designation: A2
Bank Connections: 3
Current Speed: 32 ns
Type: Other Unknown EDO
Installed Size: Not Installed
Enabled Size: Not Installed
Error Status: OK
Handle 0x0009, DMI type 6, 12 bytes
Memory Module Information
Socket Designation: A3
Bank Connections: 4
Current Speed: 32 ns
Type: Other Unknown EDO
Installed Size: Not Installed
Enabled Size: Not Installed
Error Status: OK
Handle 0x000A, DMI type 7, 19 bytes
Cache Information
Socket Designation: Internal Cache
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 128 KB
Maximum Size: 128 KB
Supported SRAM Types:
Synchronous
Installed SRAM Type: Synchronous
Speed: Unknown
Error Correction Type: Unknown
System Type: Unknown
Associativity: Unknown
Handle 0x000B, DMI type 7, 19 bytes
Cache Information
Socket Designation: Internal Cache
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 128 KB
Maximum Size: 128 KB
Supported SRAM Types:
Synchronous
Installed SRAM Type: Synchronous
Speed: Unknown
Error Correction Type: Unknown
System Type: Unknown
Associativity: Unknown
Handle 0x000C, DMI type 7, 19 bytes
Cache Information
Socket Designation: External Cache
Configuration: Enabled, Not Socketed, Level 2
Operational Mode: Write Back
Location: Internal
Installed Size: 512 KB
Maximum Size: 512 KB
Supported SRAM Types:
Synchronous
Installed SRAM Type: Synchronous
Speed: Unknown
Error Correction Type: Unknown
System Type: Unknown
Associativity: Unknown
Handle 0x000D, DMI type 7, 19 bytes
Cache Information
Socket Designation: External Cache
Configuration: Disabled, Not Socketed, Level 2
Operational Mode: Write Through
Location: Internal
Installed Size: 0 KB
Maximum Size: 1024 KB
Supported SRAM Types:
Synchronous
Installed SRAM Type: Synchronous
Speed: Unknown
Error Correction Type: Unknown
System Type: Unknown
Associativity: Unknown
Handle 0x000E, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: PRIMARY IDE
Internal Connector Type: On Board IDE
External Reference Designator:
External Connector Type: None
Port Type: Other
Handle 0x000F, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: FDD
Internal Connector Type: On Board Floppy
External Reference Designator:
External Connector Type: None
Port Type: 8251 FIFO Compatible
Handle 0x0010, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: COM1
Internal Connector Type: 9 Pin Dual Inline (pin 10 cut)
External Reference Designator:
External Connector Type: DB-9 male
Port Type: Serial Port 16450 Compatible
Handle 0x0011, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: COM2
Internal Connector Type: 9 Pin Dual Inline (pin 10 cut)
External Reference Designator:
External Connector Type: DB-9 male
Port Type: Serial Port 16450 Compatible
Handle 0x0012, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: LPT1
Internal Connector Type: DB-25 female
External Reference Designator:
External Connector Type: DB-25 female
Port Type: Parallel Port ECP/EPP
Handle 0x0013, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Keyboard
Internal Connector Type: Other
External Reference Designator:
External Connector Type: PS/2
Port Type: Keyboard Port
Handle 0x0014, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: PS/2 Mouse
Internal Connector Type: PS/2
External Reference Designator: No Detected
External Connector Type: PS/2
Port Type: Mouse Port
Handle 0x0015, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: USB
Internal Connector Type: None
External Reference Designator:
External Connector Type: Access Bus (USB)
Port Type: USB
Handle 0x0016, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: USB
Internal Connector Type: None
External Reference Designator:
External Connector Type: Access Bus (USB)
Port Type: USB
Handle 0x0017, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: USB
Internal Connector Type: None
External Reference Designator:
External Connector Type: Access Bus (USB)
Port Type: USB
Handle 0x0018, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: USB
Internal Connector Type: None
External Reference Designator:
External Connector Type: Access Bus (USB)
Port Type: USB
Handle 0x0019, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: USB
Internal Connector Type: None
External Reference Designator:
External Connector Type: Access Bus (USB)
Port Type: USB
Handle 0x001A, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: USB
Internal Connector Type: None
External Reference Designator:
External Connector Type: Access Bus (USB)
Port Type: USB
Handle 0x001B, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: USB
Internal Connector Type: None
External Reference Designator:
External Connector Type: Access Bus (USB)
Port Type: USB
Handle 0x001C, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: USB
Internal Connector Type: None
External Reference Designator:
External Connector Type: Access Bus (USB)
Port Type: USB
Handle 0x001D, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: USB
Internal Connector Type: None
External Reference Designator:
External Connector Type: Access Bus (USB)
Port Type: USB
Handle 0x001E, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: USB
Internal Connector Type: None
External Reference Designator:
External Connector Type: Access Bus (USB)
Port Type: USB
Handle 0x001F, DMI type 9, 13 bytes
System Slot Information
Designation: PCI
Type: 32-bit PCI
Current Usage: Available
Length: Long
ID: 6
Characteristics:
5.0 V is provided
3.3 V is provided
PME signal is supported
SMBus signal is supported
Handle 0x0020, DMI type 9, 13 bytes
System Slot Information
Designation: PCI
Type: 32-bit PCI
Current Usage: Available
Length: Long
ID: 7
Characteristics:
5.0 V is provided
3.3 V is provided
PME signal is supported
SMBus signal is supported
Handle 0x0021, DMI type 9, 13 bytes
System Slot Information
Designation: AGP
Type: 32-bit AGP
Current Usage: Available
Length: Long
ID: 8
Characteristics:
5.0 V is provided
Handle 0x0022, DMI type 9, 13 bytes
System Slot Information
Designation: PCI Express x16
Type: x16 PCI Express
Current Usage: Available
Length: Other
ID: 16
Characteristics:
3.3 V is provided
Handle 0x0023, DMI type 9, 13 bytes
System Slot Information
Designation: PCI Express x4
Type: x4 PCI Express
Current Usage: Available
Length: Other
ID: 32
Characteristics:
3.3 V is provided
Handle 0x0024, DMI type 13, 22 bytes
BIOS Language Information
Installable Languages: 3
n|US|iso8859-1
n|US|iso8859-1
r|CA|iso8859-1
Currently Installed Language: n|US|iso8859-1
Handle 0x0025, DMI type 16, 15 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 2 GB
Error Information Handle: Not Provided
Number Of Devices: 4
Handle 0x0026, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x0025
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 512 MB
Form Factor: DIMM
Set: None
Locator: A0
Bank Locator: Bank0/1
Type: Unknown
Type Detail: None
Speed: 800 MHz (1.2 ns)
Manufacturer:
Serial Number:
Asset Tag:
Part Number:
Handle 0x0027, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x0025
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 512 MB
Form Factor: DIMM
Set: None
Locator: A1
Bank Locator: Bank2/3
Type: Unknown
Type Detail: None
Speed: 800 MHz (1.2 ns)
Manufacturer:
Serial Number:
Asset Tag:
Part Number:
Handle 0x0028, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x0025
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: No Module Installed
Form Factor: DIMM
Set: None
Locator: A2
Bank Locator: Bank4/5
Type: Unknown
Type Detail: None
Speed: 800 MHz (1.2 ns)
Manufacturer:
Serial Number:
Asset Tag:
Part Number:
Handle 0x0029, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x0025
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: No Module Installed
Form Factor: DIMM
Set: None
Locator: A3
Bank Locator: Bank6/7
Type: Unknown
Type Detail: None
Speed: 800 MHz (1.2 ns)
Manufacturer:
Serial Number:
Asset Tag:
Part Number:
Handle 0x002A, DMI type 19, 15 bytes
Memory Array Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x0003FFFFFFF
Range Size: 1 GB
Physical Array Handle: 0x0025
Partition Width: 32
Handle 0x002B, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x0001FFFFFFF
Range Size: 512 MB
Physical Device Handle: 0x0026
Memory Array Mapped Address Handle: 0x002A
Partition Row Position: 1
Handle 0x002C, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00020000000
Ending Address: 0x0003FFFFFFF
Range Size: 512 MB
Physical Device Handle: 0x0027
Memory Array Mapped Address Handle: 0x002A
Partition Row Position: 1
Handle 0x002D, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x000000003FF
Range Size: 1 kB
Physical Device Handle: 0x0028
Memory Array Mapped Address Handle: 0x002A
Partition Row Position: 1
Handle 0x002E, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x000000003FF
Range Size: 1 kB
Physical Device Handle: 0x0029
Memory Array Mapped Address Handle: 0x002A
Partition Row Position: 1
Handle 0x002F, DMI type 32, 11 bytes
System Boot Information
Status: No errors detected
Handle 0x0030, DMI type 188, 244 bytes
OEM-specific Type
Header and Data:
BC F4 30 00 00 00 00 40 00 00 00 00 00 00 00 00
00 00 00 00 01 06 16 00 00 00 00 00 03 00 00 00
00 00 3F 00 00 00 00 00 01 00 00 00 00 00 00 00
02 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00
04 00 00 00 00 00 00 00 05 00 00 00 00 00 00 00
06 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00
40 00 10 0A 00 00 00 00 00 00 02 00 EF 02 00 5D
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
E0 3F 38 00 00 00 00 00 00 00 00 00 00 00 00 00
46 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00
24 F2 7D 5D 20 13 12 00 10 0C 01 00 6B 00 10 77
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
Handle 0x0031, DMI type 190, 212 bytes
OEM-specific Type
Header and Data:
BE D4 31 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
Handle 0x0032, DMI type 192, 244 bytes
OEM-specific Type
Header and Data:
C0 F4 32 00 18 17 17 18 18 18 17 17 18 00 00 00
14 14 14 13 13 15 14 13 14 00 00 00 29 00 00 00
17 16 15 17 18 17 18 17 17 14 15 16 15 13 14 14
15 14 2B 00 00 00 22 32 11 20 20 25 20 00 22 32
11 20 20 25 20 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
Handle 0x0033, DMI type 194, 244 bytes
OEM-specific Type
Header and Data:
C2 F4 33 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
Handle 0x0034, DMI type 127, 4 bytes
End Of Table
[-- Attachment #3: Type: text/plain, Size: 153 bytes --]
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [lm-sensors] hwmon-vid driver from linux 2.6.29
2009-05-14 19:07 [lm-sensors] hwmon-vid driver from linux 2.6.29 Rudolf Marek
` (8 preceding siblings ...)
2009-06-08 18:03 ` Hleb Valoshka
@ 2009-06-08 18:19 ` Jean Delvare
2009-06-16 14:58 ` Hleb Valoshka
` (3 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: Jean Delvare @ 2009-06-08 18:19 UTC (permalink / raw)
To: lm-sensors
On Mon, 8 Jun 2009 21:03:32 +0300, Hleb Valoshka wrote:
> On 6/8/09, Jean Delvare <khali@linux-fr.org> wrote:
> > For completeness, please also provide the output of:
> > isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 7
>
> su@globus-debian:~$ sudo isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 7
> [sudo] password for globus:
> 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 16 00 10 1a 00 00 00 80 00 00 00 1f 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 02 20 02 38 00 00 00 00 00 00 00 00 00 00
> 70: 00 01 00 38 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 00 00 80 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 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 00
> f0: 00 00 00 00 00 00 27 00 00 00 00 00 32 00 00 00
VID input value is alternatively available at 0xfc, but as you can see
the value is the same: 0x32, which we know is not correct.
> > And also tell me which revision is printed when you load the it87
> > driver.
>
> it87: Found IT8716F chip at 0x228, revision 0
A revision C chip... for what it's worth.
> it87: in3 is VCC (+5V)
> it87: in7 is VCCH (+5V Stand-By)
You can use this information to tweak your configuration file. Ideally
the driver would export the labels...
> > You could contact the motherboard vendor and tell them about the
> > problem (the question is "Is VID5 properly routed from CPU to
> > IT8716F?") and see what they have to say about this.
>
> The question is sent.
OK, thanks. Please let us know if you manage to get something useful.
> > I don't really know how to work around this. I suspect that only the
> > late 0Fh family CPUs actually make use of VID5. If I am right then we
> > could tweak the hwmon-vid VRM selection table and use 5-pin VID (VRM
> > code 24) for some of the 0Fh family CPUs. I don't know where to put the
> > limit, and this is fixing the problem where it is not... which is
> > likely to cause even more problems on other systems in the future.
>
> AFAIR my CPU is based on early revisions of Brisban core.
Correct.
> > Maybe we can have a DMI-based workaround either in it87 or hwmon-vid.
> > This is ugly and we avoid it as much as possible, but if there's no
> > other way... Hleb, please provide the output of dmidecode on your
> > system.
>
> It's in attachment
OK, thanks. The DMI data is good so at least we know we can use it for
a mainboard-specific quirk if needed.
--
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
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [lm-sensors] hwmon-vid driver from linux 2.6.29
2009-05-14 19:07 [lm-sensors] hwmon-vid driver from linux 2.6.29 Rudolf Marek
` (9 preceding siblings ...)
2009-06-08 18:19 ` Jean Delvare
@ 2009-06-16 14:58 ` Hleb Valoshka
2009-06-24 17:47 ` Hleb Valoshka
` (2 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: Hleb Valoshka @ 2009-06-16 14:58 UTC (permalink / raw)
To: lm-sensors
On 6/8/09, Jean Delvare <khali@linux-fr.org> wrote:
1-st: sorry guys, but I'm stupid asshole. I did not wrote that only
`vid' is incorrect. Every in[0-8] returns correct value.
>> > You could contact the motherboard vendor and tell them about the
>> > problem (the question is "Is VID5 properly routed from CPU to
>> > IT8716F?") and see what they have to say about this.
>>
>> The question is sent.
>
> OK, thanks. Please let us know if you manage to get something useful.
Hah. They replyed. "Try using Easy Tune S/W for monitoring voltages."
Stupid windoze-addicts.
--
http://375gnu.wordpress.com
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [lm-sensors] hwmon-vid driver from linux 2.6.29
2009-05-14 19:07 [lm-sensors] hwmon-vid driver from linux 2.6.29 Rudolf Marek
` (10 preceding siblings ...)
2009-06-16 14:58 ` Hleb Valoshka
@ 2009-06-24 17:47 ` Hleb Valoshka
2009-06-25 8:06 ` Jean Delvare
2009-06-25 13:50 ` Hleb Valoshka
13 siblings, 0 replies; 15+ messages in thread
From: Hleb Valoshka @ 2009-06-24 17:47 UTC (permalink / raw)
To: lm-sensors
On 6/8/09, Jean Delvare <khali@linux-fr.org> wrote:
>> > You could contact the motherboard vendor and tell them about the
>> > problem (the question is "Is VID5 properly routed from CPU to
>> > IT8716F?") and see what they have to say about this.
>> The question is sent.
> OK, thanks. Please let us know if you manage to get something useful.
They have replied.
=All voltages and monitoring is properly routed in our m/b's. If you
use old s/w with Phenom CPU, it will not be monitored properly in some
points by 3rd party s/w. We recommend you to use s/w for Windows,
because we don't have s/w for your OS.
=
--
http://375gnu.wordpress.com
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [lm-sensors] hwmon-vid driver from linux 2.6.29
2009-05-14 19:07 [lm-sensors] hwmon-vid driver from linux 2.6.29 Rudolf Marek
` (11 preceding siblings ...)
2009-06-24 17:47 ` Hleb Valoshka
@ 2009-06-25 8:06 ` Jean Delvare
2009-06-25 13:50 ` Hleb Valoshka
13 siblings, 0 replies; 15+ messages in thread
From: Jean Delvare @ 2009-06-25 8:06 UTC (permalink / raw)
To: lm-sensors
Hi Hleb,
On Wed, 24 Jun 2009 20:47:44 +0300, Hleb Valoshka wrote:
> On 6/8/09, Jean Delvare <khali@linux-fr.org> wrote:
> >> > You could contact the motherboard vendor and tell them about the
> >> > problem (the question is "Is VID5 properly routed from CPU to
> >> > IT8716F?") and see what they have to say about this.
> >> The question is sent.
> > OK, thanks. Please let us know if you manage to get something useful.
>
> They have replied.
>
> => All voltages and monitoring is properly routed in our m/b's. If you
> use old s/w with Phenom CPU, it will not be monitored properly in some
> points by 3rd party s/w. We recommend you to use s/w for Windows,
> because we don't have s/w for your OS.
> =
Thanks for transmitting the information. Their vague warning about the
Phenom doesn't apply to your case as you have a 0Fh family, not 10h
family CPU. Not that it would be terribly useful anyway, as they do not
say _why_ 3rd party software could get it wrong. And they did not
specifically answered to the question we asked about VID5.
Our testing was pretty clear that the value of VID5 was not correct. If
they can't explain that then I fear they won't be of any help to us :(
As you may have seen, I have posted a patch meanwhile, which should
work around the problem on your board and possibly others. Did you have
the opportunity to test it?
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [lm-sensors] hwmon-vid driver from linux 2.6.29
2009-05-14 19:07 [lm-sensors] hwmon-vid driver from linux 2.6.29 Rudolf Marek
` (12 preceding siblings ...)
2009-06-25 8:06 ` Jean Delvare
@ 2009-06-25 13:50 ` Hleb Valoshka
13 siblings, 0 replies; 15+ messages in thread
From: Hleb Valoshka @ 2009-06-25 13:50 UTC (permalink / raw)
To: lm-sensors
On 6/25/09, Jean Delvare <khali@linux-fr.org> wrote:
> As you may have seen, I have posted a patch meanwhile, which should
> work around the problem on your board and possibly others. Did you have
> the opportunity to test it?
Yes, it works good.
--
http://375gnu.wordpress.com
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 15+ messages in thread