Ticket #2298 (closed defect: fixed)

Opened 10 months ago

Last modified 2 months ago

EPIA-SN sensor

Reported by: ticket Assigned to: juergh
Priority: major Milestone:
Component: kernel Version: 3.0.0
Keywords: Cc: whirleyes@gmail.com, disk_91@hotmail.com

Description

I ran ubuntu server(hardy) with this board but i cant get the lm-sensors to detect any sensor on this board.. behind the board i can find a SMSC SCH3112 chip 

 System EPIA-SN18000

root@blackpearl:/usr/share/lm-sensors# sensors -v
sensors version 3.0.0 with libsensors version 3.0.0
root@blackpearl:/usr/share/lm-sensors# uname -r
2.6.24-4-generic

before i run sensors-detect, i run 

modprobe dme1737

then 

root@blackpearl:/usr/share/lm-sensors# sensors-detect
# sensors-detect revision 5016 (2007-11-11 22:20:16 +0100)

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

We can start with probing for (PCI) I2C or SMBus adapters.
Do you want to probe now? (YES/no): y
Probing for PCI bus adapters...
Use driver `i2c-viapro' for device 0000:00:11.0: VIA Technologies VT8251 South Bridge

We will now try to load each adapter module in turn.
Module `i2c-viapro' already loaded.
If you have undetectable or unsupported adapters, you can have them
scanned by manually loading the modules before running this script.

We are now going to do the I2C/SMBus adapter probings. Some chips may
be double detected; we choose the one with the highest confidence
value in that case.
If you found that the adapter hung after probing a certain address,
you can specify that address to remain unprobed.

Next adapter: SMBus Via Pro adapter at 0400 (i2c-0)
Do you want to scan it? (YES/no/selectively): y
Client found at address 0x50
Probing for `Analog Devices ADM1033'...                     No
Probing for `Analog Devices ADM1034'...                     No
Probing for `SPD EEPROM'...                                 Yes
    (confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'...                                No
Client found at address 0x51
Probing for `Analog Devices ADM1033'...                     No
Probing for `Analog Devices ADM1034'...                     No
Probing for `SPD EEPROM'...                                 Yes
    (confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'...                                No

Some chips are also accessible through the ISA I/O ports. We have to
write to arbitrary I/O ports to probe them. This is usually safe though.
Yes, you do have ISA I/O ports even if you do not have any ISA slots!
Do you want to scan the ISA I/O ports? (YES/no): y
Probing for `National Semiconductor LM78' at 0x290...       No
Probing for `National Semiconductor LM78-J' at 0x290...     No
Probing for `National Semiconductor LM79' at 0x290...       No
Probing for `Winbond W83781D' at 0x290...                   No
Probing for `Winbond W83782D' at 0x290...                   No
Probing for `Silicon Integrated Systems SIS5595'...         No
Probing for `VIA VT82C686 Integrated Sensors'...            No
Probing for `VIA VT8231 Integrated Sensors'...              No
Probing for `IPMI BMC KCS' at 0xca0...                      No
Probing for `IPMI BMC SMIC' at 0xca8...                     No

Some Super I/O chips may also contain sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): y
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor'...                   No
Trying family `SMSC'...                                     Yes
Found unknown chip with ID 0x0b00
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor'...                   No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Fintek'...                       No
Trying family `ITE'...                                      No

Some CPUs or memory controllers may also contain embedded sensors.
Do you want to scan for them? (YES/no): y
AMD K8 thermal sensors...                                   No
AMD K10 thermal sensors...                                  No
Intel Core family thermal sensor...                         No
Intel AMB FB-DIMM thermal sensor...                         No

Sorry, no sensors were detected.
Either your sensors are not supported, or they are connected to an
I2C or SMBus adapter that is not supported. See doc/FAQ,
doc/lm_sensors-FAQ.html or http://www.lm-sensors.org/wiki/FAQ
(FAQ #4.24.3) for further information.
If you find out what chips are on your board, check
http://www.lm-sensors.org/wiki/Devices for driver status.

so there is something on 0x2e/0x2f then i tried this 

root@blackpearl:/usr/share/lm-sensors# isadump 0x2e 0x2f
WARNING! Running this program can cause system crashes, data loss and worse!
I will probe address register 0x2e and data register 0x2f.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
50: ff ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 02 00 00 00 00 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 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

Attachments

from via web SN_back_H.JPG (151.5 kB) - added by ticket on 01/26/08 08:47:13.
From Via website
whirleyes_epia-sn18000.JPG (199.3 kB) - added by ticket on 01/26/08 08:48:35.
Epia-SN18000
dmidecode.txt (26.9 kB) - added by ticket on 01/26/08 18:47:54.
dmidecode

Change History

(follow-up: ↓ 2 ) 01/25/08 17:48:09 changed by juergh

  • owner changed from somebody to juergh.

Please run 'isadump -k 0x55 0x2e 0x2f 0xa'.

According to VIA pictures this board is supposed to have a SCH3114 which has a device ID of 0x7d. Don't know where the 0x0b comes from...

(in reply to: ↑ 1 ) 01/25/08 18:06:16 changed by ticket

SCH3114? yeah i did see smsc sch311* on top of the chip.. I'll try to confirmed that once i'm at home.. by the way 

root@blackpearl:/home/bp# isadump -k 0x55 0x2e 0x2f 0xa
WARNING! Running this program can cause system crashes, data loss and worse!
I will probe address register 0x2e and data register 0x2f.
Probing bank 10 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 00 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: 0b 00 00 00 00 00 2e 00 00 00 00 00 00 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 02 00 00 00 00 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 ff ff ff ff ff ff
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: 00 d1 15 0b 00 10 00 00 00 00 00 00 00 00 00 00

01/25/08 20:01:14 changed by juergh

Hmm... That doesn't look right. Can you try: isadump -y -k 0x55 0x4e 0x4f 0xa isadump -y -k 0x55 0x162e 0x162f 0xa isadump -y -k 0x55 0x164e 0x164f 0xa

01/26/08 08:47:13 changed by ticket

  • attachment from via web SN_back_H.JPG added.

From Via website

01/26/08 08:48:35 changed by ticket

  • attachment whirleyes_epia-sn18000.JPG added.

Epia-SN18000

01/26/08 08:56:08 changed by ticket

I've check my board.. Mine was SCH3112(See attached pic). The picture from via website (http://www.via.com.tw/en/products/mainboards/downloads.jsp?motherboard_id=550) was EPIA-SR20000G?? and it used SCH3114

do you need extra info about bios? dmidecode,etc... 

root@blackpearl:/home/bp# isadump -y -k 0x55 0x4e 0x4f 0xa
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
a0: ff ff ff ff ff ff ff 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

root@blackpearl:/home/bp# isadump -y -k 0x55 0x162e 0x162f 0xa
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: 00 00 00 00 00 00 00 05 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: 7c 02 00 00 44 09 2e 16 00 00 00 00 00 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 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 ff ff ff ff ff ff
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: 00 02 03 00 00 00 00 00 00 00 00 00 00 00 00 00

root@blackpearl:/home/bp# isadump -y -k 0x55 0x164e 0x164f 0xa
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
a0: ff ff ff ff ff ff ff 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

01/26/08 09:42:02 changed by khali

Juerg, I think that you missed the fact that isadump chooses the bank register automatically based on the base I/O address by default. The default bank register is 0x07 for standard Super-I/O addresses (0x2e and 0x4e) but 0x4e for all other addresses - which isn't what you want here. This is why the dump at 0x162e didn't produce the expected result, although I do believe this is the correct address.

Reporter, please try: isadump -y -k 0x55 0x162e 0x162f 0xa 0x07

01/26/08 10:35:42 changed by ticket

by the you can call me ismail.. please add cc to whirleyes at gmail dot com (i forgot to do that) 

root@blackpearl:/var/www/phpsysinfo/includes/xml# isadump -y -k 0x55 0x162e 0x162f 0xa 0x07
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: 00 00 00 00 00 00 00 0a 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: 7c 02 00 00 44 09 2e 16 00 00 00 00 00 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: 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 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 ff ff ff ff ff ff
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: 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00

01/26/08 10:44:45 changed by khali

  • cc set to whirleyes@gmail.com.

01/26/08 17:46:10 changed by juergh

Yes, 0x162e seems to be the correct address and it is a sch3112 (id 0x7c at address 0x20). Wow, unusual... I have to think about how to best fix sensors-detect to scan this address as well. And I also need to fix the dme1737 driver to include probing the non-standard LPC addresses.

Jean, do you think there is a device behind 0x2e/2f or is it bogus?

01/26/08 18:07:59 changed by khali

I think that the chip at 0x2e is also the SCH3112. See how the register value at 0x26 matches, and also the 0xa0-0xaf row. Maybe it is emulating some other device somehow, I just don't know.

I don't know how to support this either. I don't think we want sensors-detect to probe addresses 0x162e/0x162f, these are not standard ports and there could be about anything at this address. As the probing involves writing to port 0x162e, it could have nasty effects. Same goes for the dme1737 driver, writing to an arbitrary port doesn't sound good. We might have to provide a module parameter to let the user specify the Super-I/O address, and/or identify this specific motherboard using DMI attributes.

01/26/08 18:47:54 changed by ticket

  • attachment dmidecode.txt added.

dmidecode

01/26/08 18:51:21 changed by ticket

i wish i could help.. here are some info from dmidecode btw, any news on VIA C7 cpu diode??

01/27/08 08:45:50 changed by khali

  • component changed from sensors to kernel.

Unfortunately most DMI data is missing, so identifying this board using DMI data will not work. All we can do is add a "probe all addresses" parameter to the dme1737 driver that will probe addresses 0x162e and 0x164e in addition to the standard ones.

01/29/08 15:18:50 changed by ticket

I also look for a solution to monitor this board. If you have any information on how to fix the problem manually i'm interrested... I'll take a look to dme1737 kernel module to do it by myself, but any information will help me. I do not know how to be added in cc, please add disk_91 AT hotmail DOT com.

If you need any assistance from me, I can extract what information you need or test any patch with my board, just ask.

01/29/08 19:52:44 changed by juergh

  • cc changed from whirleyes@gmail.com to whirleyes@gmail.com, disk_91@hotmail.com.

I don't have the time right now to work on this, I have other things I need to take care of first. In the meantime you can try to replace the following two lines in dme1737_init:

if (dme1737_isa_detect(0x2e, &addr) &&

dme1737_isa_detect(0x4e, &addr)) {

with:

if (dme1737_isa_detect(0x162e, &addr) &&

dme1737_isa_detect(0x164e, &addr)) {

Let us know how it goes, i.e., post the /var/log/messages log after loading the driver.

01/30/08 23:41:27 changed by ticket

I did the following modifications, modprobe the module and get this output with dmesg

- if (dme1737_i2c_get_features(0x2e, data) &&
- dme1737_i2c_get_features(0x4e, data)) {
---
+ if (dme1737_i2c_get_features(0x162e, data) &&
+ dme1737_i2c_get_features(0x164e, data)) {

and

- if (dme1737_isa_detect(0x2e, &addr) &&
- dme1737_isa_detect(0x4e, &addr)) {
---
+ if (dme1737_isa_detect(0x162e, &addr) &&
+ dme1737_isa_detect(0x164e, &addr)) {

the result is:
i2c /dev entries driver
dme1737 dme1737.2672: Found a SCH311x chip at 0x0a70
dme1737 dme1737.2672: Optional features: pwm3=yes, pwm5=no, pwm6=no, fan3=yes, fan4=no, fan5=no, fan6=no.
hwmon-vid: Unknown VRM version of your x86 CPU

After, by running sensors, I only get this : epia:~ # sensors sch311x-isa-0a70 Adapter: ISA adapter

as precision : - kernel version is 2.6.22 with dme1737.c imported from 2.6.24 - lm_sensor version : sensors version 2.10.4 with libsensors version 2.10.4

I will try to update lm_sensors

01/30/08 23:46:26 changed by juergh

Try lm_sensors-3.0.1 from http://www.lm-sensors.org/wiki/Download.

01/30/08 23:49:01 changed by ticket

After compiling and installing sensors version 3.0.1 with libsensors version 3.0.1, the result is really better ;) epia:/usr/local/bin # ./sensors
sch311x-isa-0a70
Adapter: ISA adapter
in0: +0.00 V (min = +0.00 V, max = +6.64 V) ALARM
in1: +1.75 V (min = +0.00 V, max = +2.99 V)
in2: +3.29 V (min = +0.00 V, max = +4.38 V)
in3: +4.91 V (min = +0.00 V, max = +6.64 V)
in4: +11.99 V (min = +0.00 V, max = +15.94 V)
in5: +3.28 V (min = +0.00 V, max = +4.38 V)
in6: +3.16 V (min = +0.00 V, max = +4.38 V)
fan1: 0 RPM (min = 0 RPM)
fan2: 5060 RPM (min = 0 RPM)
fan3: 0 RPM (min = 0 RPM)
temp1: +41.9°C (low = -127.0°C, high = +127.0°C)
temp2: +42.4°C (low = -127.0°C, high = +127.0°C)
temp3: +41.1°C (low = -127.0°C, high = +127.0°C)
cpu0_vid: +0.000 V

01/31/08 08:06:14 changed by ticket

same here 

[166357.921061] dme1737 dme1737.2672: Found a SCH311x chip at 0x0a70
[166357.921075] dme1737 dme1737.2672: Optional features: pwm3=yes, pwm5=no, pwm6=no, fan3=yes, fan4=no, fan5=no, fan6=no.
[166357.921094] hwmon-vid: Unknown VRM version of your x86 CPU
root@blackpearl:/lib/modules/2.6.24-5-generic/kernel/drivers/hwmon# sensors
sch311x-isa-0a70
Adapter: ISA adapter
in0:         +0.00 V  (min =  +0.00 V, max =  +6.64 V)   ALARM
in1:         +1.77 V  (min =  +0.00 V, max =  +2.99 V)
in2:         +3.34 V  (min =  +0.00 V, max =  +4.38 V)
in3:         +5.14 V  (min =  +0.00 V, max =  +6.64 V)
in4:        +11.91 V  (min =  +0.00 V, max = +15.94 V)
in5:         +3.29 V  (min =  +0.00 V, max =  +4.38 V)
in6:         +3.16 V  (min =  +0.00 V, max =  +4.38 V)
fan1:          0 RPM  (min =    0 RPM)
fan2:       6000 RPM  (min =    0 RPM)
fan3:          0 RPM  (min =    0 RPM)
temp1:       +31.6°C  (low  = -127.0°C, high = +127.0°C)
temp2:       +33.3°C  (low  = -127.0°C, high = +127.0°C)
temp3:       +33.8°C  (low  = -127.0°C, high = +127.0°C)
cpu0_vid:   +0.000 V

02/01/08 14:16:27 changed by khali

hwmon-vid: Unknown VRM version of your x86 CPU

What CPU is this? You might need to backport one of the following patches to get VID support:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=734a12a36676ad3b9418fa5a829c518afec02b8a
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e46751bfd69839edd15ee54cabbeed8e801a4274

02/01/08 16:30:30 changed by ticket

CPU is VIA C7.. http://www.via.com.tw/en/products/processors/c7/

temp1 probably CPU temp,temp3 probably North Bridge

I run watch sensors and unplug the cpu fan.. temp1 rise to 42degre. temp3 rise to 37degre.

North Bridge and CPU share same heatsink.So I put other fan on top of cpu side.. temp1 goes down more than temp3 put it top of North Bridge side.. temp3 goes down more than temp1

during those test temp2 goes up and a little. Hope it help

02/01/08 17:26:45 changed by ticket

sorry if unnecessary. my hwmon-vid.c look same as 8 May 2007(support for esther) 

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

02/03/08 12:26:03 changed by khali

This appears to be a new-generation C7 (presumably what VIA call C7-D on their website) which the hwmon-vid driver doesn't support yet. You may try writing 13 to /sys/class/hwmon/hwmon0/device/vrm, to have your CPU handled as the original C7: 

echo 13 > /sys/class/hwmon/hwmon0/device/vrm

The dme1737 driver will then be able to decode the CPU VID pins, if they are properly wired on your system. If the cpu0_vid value makes sense, we can add the CPU ID to hwmon-vid permanently.

02/03/08 12:42:10 changed by ticket

thank you.. it worked! 

root@blackpearl:/home/bp# echo 13 > /sys/class/hwmon/hwmon0/device/vrm
root@blackpearl:/home/bp# sensors
sch311x-isa-0a70
Adapter: ISA adapter
V5stby:            +0.00 V  (min =  +0.00 V, max =  +6.64 V)   ALARM
Vccp:              +1.77 V  (min =  +0.00 V, max =  +2.99 V)
V3.3:              +3.34 V  (min =  +0.00 V, max =  +4.38 V)
V5:                +5.14 V  (min =  +0.00 V, max =  +6.64 V)
V12:              +11.92 V  (min =  +0.00 V, max = +15.94 V)
V3.3stby:          +3.28 V  (min =  +0.00 V, max =  +4.38 V)
Vbat:              +3.16 V  (min =  +0.00 V, max =  +4.38 V)
Case Fan:            0 RPM  (min =    0 RPM)
CPU Fan:          3422 RPM  (min =    0 RPM)
Fan3:                0 RPM  (min =    0 RPM)
CPU Temp:          +35.3°C  (low  = -127.0°C, high = +127.0°C)
Int Temp:          +37.1°C  (low  = -127.0°C, high = +127.0°C)
North Bridge Temp: +37.0°C  (low  = -127.0°C, high = +127.0°C)
cpu0_vid:         +1.708 V

02/03/08 12:46:39 changed by ticket

but value is very high.. It was 1.162V in BIOS

02/03/08 13:03:00 changed by khali

Well, Vccp reads +1.77 V, which isn't too far away from +1.708 V.

I think that the C7-D can scale its frequency and voltage dynamically, and what you saw in the BIOS could be its low power operating point. You might be able to get Linux to do the same using the e_powersaver driver. Then both the Vccp (in1) and cpu0_vid readings should change depending on the CPU operating point.

But of course it is also possible that the C7-D uses a different table for VID decoding.

02/04/08 20:05:58 changed by ticket

I had the same issue with VRM, could you explain me what is VRM ?

Other question ... I saw your temperature around 37°C, on my board, I try to reduce processor speed to stop fan and reducing speed works well ... but temperature grows up to 54°C, even low frequency with fan @ 6000RPM

fan1: 0 RPM (min = 0 RPM) fan2: 6081 RPM (min = 0 RPM) fan3: 0 RPM (min = 0 RPM) temp1: +47.1°C (low = -127.0°C, high = +127.0°C) temp2: +46.8°C (low = -127.0°C, high = +127.0°C) temp3: +45.2°C (low = -127.0°C, high = +127.0°C)

with :

cpu MHz : 798.024

Do you have the same situation ? any idea to reduce heat ? because that really small fan make so much noise ! and same board @1G from epia is fan less !!

Any idea of what is the normal max temperature acceptable for this CPU ?

02/04/08 20:23:30 changed by khali

All modern CPUs have pins dedicated to exporting the core voltage they expect. This lets the motherboard set the core voltage automatically without having to set jumpers on the board. We use "VRM" (or sometimes "VRD") to designate the tables that convert the value of the pins to an actual voltage value. Different CPU models use different tables.

Also read this (slightly outdated) document:
lm-sensors/branches/lm-sensors-3.0.0/doc/vid

Usually the kernel picks the right conversion table automatically so the user doesn't have to care about the details, but for brand new CPUs, the kernel doesn't know what table to use so the user must provide the (arbitrary) value that corresponds to the right conversion table.

(follow-up: ↓ 29 ) 02/05/08 03:28:12 changed by ticket

I just think that this cpu used a different VID table.. For now, I'm still not be able to adjust the cpu speed but does lowering the cpu speed reduce the Vid for this CPU? cat /proc/cpuinfo say stepping is 0.. from what i read it used the C-state an P-state to control the cpu power. voltage 0.99V~1.20V http://www.via.com.tw/en/downloads/presentations/events/vtf2005/vtf05%20_mp_centaur.pdf but it's a C7-M.. i don't know My cpu is generic C7 or the new C7-D

Info i grab from acpi 

cat proc/acpi/processor/P001/info
processor id:            0
acpi id:                 1
bus mastering control:   no
power management:        no
throttling control:      yes
limit interface:         yes

cat proc/acpi/processor/P001/power
active state:            C0
max_cstate:              C8
bus master activity:     00000000
maximum allowed latency: 8000 usec
states:
    C1:                  type[C1] promotion[--] demotion[--] 
latency[000] usage[00000000] duration[00000000000000000000]

cat proc/acpi/processor/P001/throttling
state count:             16
active state:            T0
state available: T0 to T15
states:
   *T0:                  100%
    T1:                  93%
    T2:                  87%
    T3:                  81%
    T4:                  75%
    T5:                  69%
    T6:                  62%
    T7:                  56%
    T8:                  50%
    T9:                  44%
    T10:                  38%
    T11:                  31%
    T12:                  25%
    T13:                  19%
    T14:                  13%
    T15:                  07%

just a little experiment.. I attached the system to watt-meter.
My system(Epia-SN1.8G + 3x500GB HDD + 1x2GB Compact Flash)
Watt-meter: idle-- 52Watt, running Hardinfo-- 62Watt
CPU Temp:Idle-- 35°C, running Hardinfo-- 49°C
cpu0_vid:Idle-- 1.708V, running Hardinfo-- 1.708V

so where does the 10watt and heat come from? System run on the CF card(low voltage). The other 3 disk remain idle.

02/09/08 10:46:09 changed by ticket

the e_powersaver now... these are from dmesg after loading the driver 

[   38.604281] eps: Detected VIA C7-M
[   38.604289] eps: Current voltage = 1180mV
[   38.604292] eps: Current multiplier = 9
[   38.604295] eps: Highest voltage = 1196mV
[   38.604298] eps: Highest multiplier = 9
[   38.604301] eps: Lowest voltage = 956mV
[   38.604304] eps: Lowest multiplier = 4
[   38.604308] eps: khz = 1795590
[   38.604310] eps: fsb = 199510

the Vccp now in range of 1.43V to 1.76V cpu0_vid still remain +1.708 V how do I alter the cpu VID table?

(in reply to: ↑ 27 ) 02/10/08 20:54:07 changed by khali

Replying to ticket:

For now, I'm still not be able to adjust the cpu speed but does lowering the cpu speed reduce the Vid for this CPU?

Yes, typically a lower frequency allows a lower core voltage and the VID pin levels should change dynamically.

I note that 1.76/1.43 = 1.230 while 1.180/0.956 = 1.234 so the change of Vccp value seems to match what the e_powersaver driver prints, just with a ratio of 3/2. Maybe you need the the following compute statement: 

   compute in1 @*2/3, @*3/2

However I admit that I am very surprised because usually the voltages are scaled down by external resistors, not up.

Another possibility is that the LSB value for in1 is different from what the driver implements. Juerg, do you know if it is possible that the SMSC SCH3112 has a different voltage range for in1? The dme1737 driver assumes range 0-2.250V but it seems that 0-1.500V would match the experimental results instead.

About VID/VRM: 1.708V is the maximum supported by VRM "13". This means that all VID pins are set to 0. This certainly means that the VID inputs aren't wired on this motherboard, which is confirmed by the fact that the value doesn't change when e_powersaver indicates it should. So you can simply ignore cpu0_vid.

02/11/08 06:51:43 changed by juergh

Yes, the range for in1 is different for the sch311x. Good catch! For the dme1737 it's 0-3V and for the sch311x it's 0-2V. I'll fix the driver.

10/01/08 19:05:14 changed by juergh

  • status changed from new to closed.
  • resolution set to fixed.

The dme1737 driver has been fixed to adjust the inX range according to the detected chip type.