On 6/8/09, Jean Delvare <khali at linux-fr.org> wrote: > For completeness, please also provide the output of: > isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 7 su at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: file Type: application/octet-stream Size: 17927 bytes Desc: not available Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20090608/9ca57d8b/attachment-0001.obj