Skip to contentSkip to conversation

sensors-detect killed my CPU

lm-sensors New Achim Gottinger 6 participants 37 messages May 2, 2008 – May 7, 2008 3 messages not in the archive

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

Hi lm-sensors developers.

I just ran sensors-detect on my phenom system (9850BE, Sapphire AM2RD790 Board, 2x1GB Crucial Ballistix DDR2-6400). It froze during SMbus scan and now the cpu seems to be defect.
The board stucks at C1 state during post, means it's a probem with the memory substytem.
I tried the cpu in another board (M3A) and no post here also. The system works fine with an 9600BE so it's definately the cpu, whom died during the sensors-detect run.

Greets
achim~

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

#1 lore raw

Hi Achim,

Quoted 8 lines · Achim Gottinger

I just ran sensors-detect on my phenom system (9850BE, Sapphire AM2RD790 Board, 2x1GB Crucial Ballistix DDR2-6400). It froze during SMbus scan and now the cpu seems to be defect.
The board stucks at C1 state during post, means it's a probem with the memory substytem.
I tried the cpu in another board (M3A) and no post here also. The system works fine with an 9600BE so it's definately the cpu, whom died during the sensors-detect run.

Hmm, that's bad. First report of this type as far as I remember. Which version of sensors-detect did you run exactly?

Do you know if the Sapphire AM2RD790 has some special chip on the SMBus? I see that this board is "the clear choice for overclocking enthusiasts", maybe some overclocking chip on the SMBus was accessed during SMBus probing of sensors-detect and it didn't like that... Do you have a contact at Sapphire who could answer such technical questions?

Was the CPU overclocked at the time you ran sensors-detect?

If you can provide the dmidecode output for the Sapphire AM2RD790, maybe we can blacklist it in sensors-detect or even prevent the SMBus driver from loading (we'll need the output of lspci -nnv for that). In the meantime I'll put a note on our website so that other users don't kill their CPUs too.

Signature · 6 lines
Jean Delvare

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
#2 lore raw
In reply to Achim Gottinger

Hi,

It can be something other, because many boards have problem with this processor, because they have insufficient supply circuits. This processor has 125W max power, and this is too much for many boards. Yesterday my colleague bought this processor with board ASUS M3A-H/HDMI and it still resets. When he put out one memory, it sometimes works.

Best regards,

Pavel Ruzicka

Quoted 9 lines

I just ran sensors-detect on my phenom system (9850BE, Sapphire AM2RD790 Board, 2x1GB Crucial Ballistix DDR2-6400). It froze during SMbus scan and now the cpu seems to be defect.
The board stucks at C1 state during post, means it's a probem with the memory substytem.
I tried the cpu in another board (M3A) and no post here also. The system works fine with an 9600BE so it's definately the cpu, whom died during the sensors-detect run.

Quoted 8 lines

Greets
achim~

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

author
#3 lore raw
In reply to Achim Gottinger

Hi Jean and Pavel,

Thank you for the fast replies.

I run debian lenny 64bit which comes with sensors version 3.0.1. The debian package version is 3.0.1-5.

The board has no special overclocking chip. It comes with an 8-pin connector for the 12V rails so the cpu can use up to 36A and therefore has more headroom for overclocking at my settings the cpu used max 11-12A. (I have an Gigabyte Odin PSU with monitoring software whom shows the power usage of the single rails and tested this issue before). Also it has few more memory settings and allows to adjust the cpu and nb voltage in steps ov 0.0625V. Those features make it overclockers first choice.

The cpu was abit overclocked while i ran sensors-detect. I used an 13.5 cpu multi instead of an 12.5 multi and had uppdet the cpu voltage from 1.3V to 1.3125V. Everything else was at stock.
Before I ran sensors-detect I ran the phoronix-test-suite for benchmarking purpose whom showed no problems. Normaly one of the cores stopps responding if I overclock the system too far, that did not happen before at 2.7GHz, it started at around 2.8GHz.

I have not yet contacted Sapphire. The board however is a clone of the DFI Lanparty UT790FX. On an overclocker forum I found an user report whom had a similar problem. In his case speedfan caused his board/cpu not to post. He contacted DFI and they said it can be that lower io access can cripple the bios. There are other users on that forum whom reported similar issues after starting sandra or evereset. Sometimes it is the bios getting corrupted sometimes it's the cpu getting stuck at C1 stage during post. Sometimes it helps to cool down the cpu below zero and it posts back. In other cases it helped to use DDR2-800 ram instead of DDR2-1066 ram. I tried to reflash the bios and cleared the cmos and dmi area but it did not help. I also tried to use DDR2-800 memory without luck. I can sort out a crippled bios in my case bcause the board still works fine with an 9600BE.

The board uses the ITC8716F-S chip and the it87 module works fine if i load it manual. I'd like to look a little deeper into that sensor chip reading issues so i'll start to read the source code now to find out what happens. I attached the dmidecode and the lspci -nnv output.

---------- kenrel log output of the it87 module ----------------
it87: Found IT8716F chip at 0x228, revision 3
it87: in3 is VCC (+5V)
it87: in7 is VCCH (+5V Stand-By)
hwmon-vid: Unknown VRM version of your x86 CPU
----------------------------------------------------------------

achim~

Quoted 11 lines

Hmm, that's bad. First report of this type as far as I remember. Which version of sensors-detect did you run exactly?

Do you know if the Sapphire AM2RD790 has some special chip on the SMBus? I see that this board is "the clear choice for overclocking enthusiasts", maybe some overclocking chip on the SMBus was accessed during SMBus probing of sensors-detect and it didn't like that... Do you have a contact at Sapphire who could answer such technical questions?

Quoted 8 lines

Was the CPU overclocked at the time you ran sensors-detect?

If you can provide the dmidecode output for the Sapphire AM2RD790, maybe we can blacklist it in sensors-detect or even prevent the SMBus driver from loading (we'll need the output of lspci -nnv for that). In the meantime I'll put a note on our website so that other users don't kill their CPUs too.

# dmidecode 2.9
SMBIOS 2.5 present.
54 structures occupying 2272 bytes.
Table at 0x000F0000.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: Phoenix Technologies, LTD
Version: 6.00 PG
Release Date: 04/15/2008
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 1024 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
LS-120 boot is supported
ATAPI Zip drive boot is supported
BIOS boot specification is supported

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Unknow
Product Name: Unknow
Version: Unknow
Serial Number: Unknow
UUID: Not Present
Wake-up Type: Power Switch
SKU Number:
Family:

Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: SAPPHIRE Inc.
Product Name: PC-AM2RD790
Version: 1.0
Serial Number:

Handle 0x0003, DMI type 3, 17 bytes
Chassis Information
Manufacturer: Unknow
Type: Desktop
Lock: Not Present
Version: Unknow
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, 40 bytes
Processor Information
Socket Designation: Socket AM2
Type: Central Processor
Family: Pentium Pro
Manufacturer: AMD
ID: 22 0F 10 00 FF FB 8B 17
Signature: Type 0, Family 16, Model 2, Stepping 2 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 Phenom(tm) 9600 Quad-Core Processor
Voltage: 1.5 V
External Clock: 255 MHz
Max Speed: 3000 MHz
Current Speed: 1148 MHz
Status: Populated, Enabled
Upgrade: Socket 940
L1 Cache Handle: 0x000A
L2 Cache Handle: 0x000B
L3 Cache Handle: Not Provided
Serial Number:
Asset Tag:
Part Number:
Core Count: 2
Core Enabled: 2
Thread Count: 2
Characteristics:
64-bit capable

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: 4096 MB Maximum Total Memory Size: 16384 MB Supported Speeds:
70 ns
60 ns
50 ns
Supported Memory Types:
Standard
DIMM
Memory Module Voltage: 2.9 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: None
Current Speed: Unknown
Type: Other Unknown EDO
Installed Size: Not Installed
Enabled Size: Not Installed
Error Status: OK

Handle 0x0007, DMI type 6, 12 bytes
Memory Module Information
Socket Designation: A1
Bank Connections: None
Current Speed: Unknown
Type: Other Unknown EDO
Installed Size: Not Installed
Enabled Size: Not Installed
Error Status: OK

Handle 0x0008, DMI type 6, 12 bytes
Memory Module Information
Socket Designation: A2
Bank Connections: 4 5
Current Speed: Unknown
Type: Other Unknown EDO
Installed Size: 1024 MB (Double-bank Connection) Enabled Size: 1024 MB (Double-bank Connection) Error Status: OK

Handle 0x0009, DMI type 6, 12 bytes
Memory Module Information
Socket Designation: A3
Bank Connections: 6 7
Current Speed: Unknown
Type: Other Unknown EDO
Installed Size: 1024 MB (Double-bank Connection) Enabled Size: 1024 MB (Double-bank Connection) 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: 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 0x000C, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: PRIMARY IDE Internal Connector Type: On Board IDE External Reference Designator: Not Specified External Connector Type: None
Port Type: Other

Handle 0x000D, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: FDD Internal Connector Type: On Board Floppy External Reference Designator: Not Specified External Connector Type: None
Port Type: 8251 FIFO Compatible

Handle 0x000E, 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 0x000F, 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 0x0010, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Keyboard
Internal Connector Type: PS/2
External Reference Designator:
External Connector Type: PS/2
Port Type: Keyboard Port

Handle 0x0011, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: PS/2 Mouse
Internal Connector Type: PS/2
External Reference Designator:
External Connector Type: PS/2
Port Type: Mouse Port

Handle 0x0012, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB0 External Connector Type: Other
Port Type: USB

Handle 0x0013, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB1 External Connector Type: Other
Port Type: USB

Handle 0x0014, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB2 External Connector Type: Other
Port Type: USB

Handle 0x0015, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB3 External Connector Type: Other
Port Type: USB

Handle 0x0016, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB4 External Connector Type: Other
Port Type: USB

Handle 0x0017, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB5 External Connector Type: Other
Port Type: USB

Handle 0x0018, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB6 External Connector Type: Other
Port Type: USB

Handle 0x0019, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB7 External Connector Type: Other
Port Type: USB

Handle 0x001A, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB8 External Connector Type: Other
Port Type: USB

Handle 0x001B, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB9 External Connector Type: Other
Port Type: USB

Handle 0x001C, DMI type 9, 13 bytes
System Slot Information
Designation: PCI0
Type: 32-bit PCI
Current Usage: Available
Length: Long
ID: 1
Characteristics:
5.0 V is provided
PME signal is supported

Handle 0x001D, DMI type 9, 13 bytes
System Slot Information
Designation: PCI1
Type: 32-bit PCI
Current Usage: Available
Length: Long
ID: 2
Characteristics:
5.0 V is provided
PME signal is supported

Handle 0x001E, DMI type 9, 13 bytes
System Slot Information
Designation: PCI2
Type: 32-bit PCI
Current Usage: Available
Length: Long
ID: 3
Characteristics:
5.0 V is provided
PME signal is supported

Handle 0x001F, DMI type 9, 13 bytes
System Slot Information
Designation: PCI3
Type: 32-bit PCI
Current Usage: Available
Length: Long
ID: 4
Characteristics:
5.0 V is provided
PME signal is supported

Handle 0x0020, DMI type 9, 13 bytes
System Slot Information

	Designation: PCI-X
	Type: 32-bit PCI-X
	Current Usage: Available
	Length: Long
	ID: 1
	Characteristics:
		5.0 V is provided

Handle 0x0021, DMI type 9, 13 bytes
System Slot Information

	Designation: PCI-X
	Type: 32-bit PCI-X
	Current Usage: Available
	Length: Long
	ID: 237
	Characteristics:
		5.0 V is provided

Handle 0x0022, DMI type 9, 13 bytes
System Slot Information

	Designation: PCI-X
	Type: 32-bit PCI-X
	Current Usage: Available
	Length: Long
	ID: 7
	Characteristics:
		5.0 V is provided

Handle 0x0023, DMI type 9, 13 bytes
System Slot Information

	Designation: PCI-X
	Type: 32-bit PCI-X
	Current Usage: Available
	Length: Long
	ID: 240
	Characteristics:
		5.0 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: No Module Installed
Form Factor: DIMM
Set: None
Locator: A0
Bank Locator: Bank0/1
Type: DDR2
Type Detail: None
Speed: 4198 MHz (0.2 ns)
Manufacturer: <BAD INDEX>
Serial Number: Not Specified
Asset Tag: None
Part Number: None

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: No Module Installed
Form Factor: DIMM
Set: None
Locator: A1
Bank Locator: Bank2/3
Type: DDR2
Type Detail: None
Speed: 4198 MHz (0.2 ns)
Manufacturer: <BAD INDEX>
Serial Number: Not Specified
Asset Tag: None
Part Number: None

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: 1024 MB
Form Factor: DIMM
Set: None
Locator: A2
Bank Locator: Bank4/5
Type: DDR2
Type Detail: None
Speed: 4198 MHz (0.2 ns)
Manufacturer: <BAD INDEX>
Serial Number: Not Specified
Asset Tag: None
Part Number: None

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: 1024 MB
Form Factor: DIMM
Set: None
Locator: A3
Bank Locator: Bank6/7
Type: DDR2
Type Detail: None
Speed: 4198 MHz (0.2 ns)
Manufacturer: <BAD INDEX>
Serial Number: Not Specified
Asset Tag: None
Part Number: None

Handle 0x002A, DMI type 19, 15 bytes
Memory Array Mapped Address

	Starting Address: 0x00000000000
	Ending Address: 0x0007FFFFFFF
	Range Size: 2 GB
	Physical Array Handle: 0x0025
	Partition Width: 0

Handle 0x002B, DMI type 20, 19 bytes
Memory Device Mapped Address

	Starting Address: 0x00000000000
	Ending Address: 0x000000003FF
	Range Size: 1 kB
	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: 0x00000000000
	Ending Address: 0x000000003FF
	Range Size: 1 kB
	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: 0x0003FFFFFFF
	Range Size: 1 GB
	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: 0x00040000000
	Ending Address: 0x0007FFFFFFF
	Range Size: 1 GB
	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 11, 5 bytes
OEM Strings
String 1:

Handle 0x0031, DMI type 188, 212 bytes
OEM-specific Type

	Header and Data:
		BC D4 31 00 00 00 00 80 00 00 00 00 00 00 00 00
		00 00 00 00 00 06 16 00 00 00 00 00 08 00 00 00
		00 40 40 00 00 08 01 00 03 00 00 00 00 00 7F 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 00 00 00 00
		00 00 00 00 01 00 00 00 01 01 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		E0 3E 78 00 00 00 00 00 00 00 00 00 05 00 80 0B
		00 00 00 00 20 00 00 00 40 00 00 00 24 91 14 AE
		45 00 82 20 00 08 01 00 00 02 00 00 00 00 00 00
		44 00 90 0A 0C 00 58 3F 00 00 00 00 00 00 00 00
		00 00 00 00

Handle 0x0032, DMI type 190, 212 bytes
OEM-specific Type

	Header and Data:
		BE D4 32 00 10 05 00 00 00 00 00 00 24 A4 40 04
		C0 0F E4 2F 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 0F 00 00 00 00 00 00 00
		00 00 00 00 02 55 93 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

Handle 0x0033, DMI type 192, 244 bytes
OEM-specific Type

	Header and Data:
		C0 F4 33 00 05 00 00 00 22 32 11 20 20 25 20 00
		E7 88 71 0E F3 0D 0B 00 22 32 11 20 00 00 00 00
		11 11 12 11 00 00 00 00 00 00 00 00 0F 10 10 11
		00 00 00 00 00 11 00 20 25 20 00 2E 2E 2E 2E 0C
		0C 0C 0A 2E 2E 2E 2E 2E 2E 2E 2E 0C 0C 0C 0A 2E
		2E 2E 2E 00 0C 00 68 8C 41 06 F3 0D 0B 00 00 00
		00 00 00 00 00 00 00 00 84 00 82 00 82 00 81 00
		84 00 00 00 00 00 00 00 00 00 00 00 04 00 02 00
		02 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
		80 00 84 00 83 00 85 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 04 00 03 00 05 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 15 15 12 13 13 13 15 16 12 00 00 00
		0B 01 00 00 DC 01 00 00 DC 01 00 00 DC 01 00 00
		00 00 00 00

Handle 0x0034, DMI type 194, 244 bytes
OEM-specific Type

	Header and Data:
		C2 F4 34 00 05 00 00 00 22 32 11 20 20 25 20 00
		69 8C 51 06 F3 0D 0B 00 22 32 11 20 00 00 00 00
		10 10 11 11 00 00 00 00 00 00 00 00 0F 0F 10 0F
		00 00 00 00 00 10 00 20 25 20 00 2E 2E 2E 2E 0A
		0C 0A 0C 2E 2E 2E 2E 2E 2E 2E 2E 0A 0C 0C 0A 2E
		2E 2E 2E 00 0A 00 69 90 51 06 F3 0D 0B 00 00 00
		00 00 00 00 00 00 00 00 77 00 77 00 72 00 73 00
		77 00 00 00 00 00 00 00 00 00 00 00 17 00 17 00
		12 00 13 00 00 00 00 00 00 00 00 00 00 00 00 00
		77 00 73 00 76 00 79 00 00 00 00 00 00 00 00 00
		00 00 00 00 17 00 13 00 16 00 19 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 13 15 13 13 12 13 14 15 13 00 00 00
		1C 00 00 00 DC 01 00 00 DC 01 00 00 DC 01 00 00
		00 00 00 00

Handle 0x0035, DMI type 127, 4 bytes
End Of Table

00:00.0 Host bridge [0600]: ATI Technologies Inc RD790 Northbridge only dual slot PCI-e_GFX and HT3 K8 part [1002:5956]
Subsystem: ATI Technologies Inc RD790 Northbridge only dual slot PCI-e_GFX and HT3 K8 part [1002:5956]
Flags: bus master, 66MHz, medium devsel, latency 64
Memory at <ignored> (64-bit, non-prefetchable)
Capabilities: [c4] HyperTransport: Slave or Primary Interface
Capabilities: [40] HyperTransport: Retry Mode
Capabilities: [54] HyperTransport: UnitID Clumping
Capabilities: [9c] HyperTransport: #1a

00:07.0 PCI bridge [0604]: ATI Technologies Inc RD790 PCI to PCI bridge (PCI express gpp port D) [1002:597d] (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000d000-0000dfff
Memory behind bridge: fd800000-fd8fffff
Prefetchable memory behind bridge: 00000000fde00000-00000000fdefffff
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Root Port (Slot+), MSI 00
Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
Capabilities: [b0] Subsystem: ATI Technologies Inc Unknown device [1002:5956]
Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+
Capabilities: [100] Vendor Specific Information <?>
Capabilities: [110] Virtual Channel <?>
Kernel driver in use: pcieport-driver
Kernel modules: shpchp

00:09.0 PCI bridge [0604]: ATI Technologies Inc RD790 PCI to PCI bridge (PCI express gpp port E) [1002:597e] (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000c000-0000cfff
Memory behind bridge: fdd00000-fddfffff
Prefetchable memory behind bridge: 00000000fdc00000-00000000fdcfffff
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Root Port (Slot+), MSI 00
Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
Capabilities: [b0] Subsystem: ATI Technologies Inc Unknown device [1002:5956]
Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+
Capabilities: [100] Vendor Specific Information <?>
Capabilities: [110] Virtual Channel <?>
Kernel driver in use: pcieport-driver
Kernel modules: shpchp

00:0a.0 PCI bridge [0604]: ATI Technologies Inc RD790 PCI to PCI bridge (PCI express gpp port F) [1002:597f] (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 0000b000-0000bfff
Memory behind bridge: fdb00000-fdbfffff
Prefetchable memory behind bridge: 00000000fda00000-00000000fdafffff
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Root Port (Slot+), MSI 00
Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
Capabilities: [b0] Subsystem: ATI Technologies Inc Unknown device [1002:5956]
Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+
Capabilities: [100] Vendor Specific Information <?>
Capabilities: [110] Virtual Channel <?>
Kernel driver in use: pcieport-driver
Kernel modules: shpchp

00:0b.0 PCI bridge [0604]: ATI Technologies Inc RD790 PCI to PCI bridge (external gfx1 port A) [1002:5980] (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
I/O behind bridge: 0000e000-0000efff
Memory behind bridge: fd900000-fd9fffff
Prefetchable memory behind bridge: 00000000d0000000-00000000dfffffff
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Root Port (Slot+), MSI 00
Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
Capabilities: [b0] Subsystem: ATI Technologies Inc Unknown device [1002:5956]
Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+
Capabilities: [100] Vendor Specific Information <?>
Capabilities: [110] Virtual Channel <?>
Kernel driver in use: pcieport-driver
Kernel modules: shpchp

00:12.0 SATA controller [0106]: ATI Technologies Inc SB600 Non-Raid-5 SATA [1002:4380] (prog-if 01 [AHCI 1.0])

	Subsystem: ATI Technologies Inc SB600 Non-Raid-5 SATA [1002:4380]
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 22
	I/O ports at ff00 [size=8]
	I/O ports at fe00 [size=4]
	I/O ports at fd00 [size=8]
	I/O ports at fc00 [size=4]
	I/O ports at fb00 [size=16]
	Memory at fdfff000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [60] Power Management version 2
	Kernel driver in use: ahci
	Kernel modules: ahci

00:13.0 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI0) [1002:4387] (prog-if 10 [OHCI])
Subsystem: ATI Technologies Inc SB600 USB (OHCI0) [1002:4387]
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
Memory at fdffe000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci_hcd
Kernel modules: ohci-hcd

00:13.1 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI1) [1002:4388] (prog-if 10 [OHCI])
Subsystem: ATI Technologies Inc SB600 USB (OHCI1) [1002:4388]
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 17
Memory at fdffd000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci_hcd
Kernel modules: ohci-hcd

00:13.2 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI2) [1002:4389] (prog-if 10 [OHCI])
Subsystem: ATI Technologies Inc SB600 USB (OHCI2) [1002:4389]
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18
Memory at fdffc000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci_hcd
Kernel modules: ohci-hcd

00:13.3 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI3) [1002:438a] (prog-if 10 [OHCI])
Subsystem: ATI Technologies Inc SB600 USB (OHCI3) [1002:438a]
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 17
Memory at fdffb000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci_hcd
Kernel modules: ohci-hcd

00:13.4 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI4) [1002:438b] (prog-if 10 [OHCI])
Subsystem: ATI Technologies Inc SB600 USB (OHCI4) [1002:438b]
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18
Memory at fdffa000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci_hcd
Kernel modules: ohci-hcd

00:14.0 SMBus [0c05]: ATI Technologies Inc SBx00 SMBus Controller [1002:4385] (rev 14)
Subsystem: ATI Technologies Inc SBx00 SMBus Controller [1002:4385]
Flags: 66MHz, medium devsel
I/O ports at 0b00 [size=16]
Capabilities: [b0] HyperTransport: MSI Mapping Enable- Fixed+ Kernel driver in use: piix4_smbus
Kernel modules: i2c-piix4

00:14.1 IDE interface [0101]: ATI Technologies Inc SB600 IDE [1002:438c] (prog-if 8a [Master SecP PriP])

	Subsystem: ATI Technologies Inc SB600 IDE [1002:438c]
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
	I/O ports at 01f0 [size=8]
	I/O ports at 03f4 [size=1]
	I/O ports at 0170 [size=8]
	I/O ports at 0374 [size=1]
	I/O ports at f900 [size=16]
	Kernel driver in use: ATIIXP_IDE
	Kernel modules: ata_generic, atiixp, generic

00:14.3 ISA bridge [0601]: ATI Technologies Inc SB600 PCI to LPC Bridge [1002:438d]
Subsystem: ATI Technologies Inc SB600 PCI to LPC Bridge [1002:438d]
Flags: bus master, 66MHz, medium devsel, latency 0

00:14.4 PCI bridge [0604]: ATI Technologies Inc SBx00 PCI to PCI Bridge [1002:4384] (prog-if 01 [Subtractive decode])
Flags: bus master, VGA palette snoop, 66MHz, medium devsel, latency 64
Bus: primary=00, secondary=05, subordinate=05, sec-latency=64
I/O behind bridge: 0000a000-0000afff
Memory behind bridge: fd700000-fd7fffff
Prefetchable memory behind bridge: fd600000-fd6fffff

00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] HyperTransport Configuration [1022:1200]
Flags: fast devsel
Capabilities: [80] HyperTransport: Host or Secondary Interface

00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Address Map [1022:1201]
Flags: fast devsel

00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] DRAM Controller [1022:1202]
Flags: fast devsel

00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Miscellaneous Control [1022:1203]
Flags: fast devsel
Capabilities: [f0] Secure device <?>

00:18.4 Host bridge [0600]: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Link Control [1022:1204]
Flags: fast devsel

01:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller [11ab:4362] (rev 22)
Subsystem: Marvell Technology Group Ltd. Marvell RDK-8053 [11ab:5321]
Flags: bus master, fast devsel, latency 0, IRQ 1275
Memory at fd8fc000 (64-bit, non-prefetchable) [size=16K]
I/O ports at de00 [size=256]
[virtual] Expansion ROM at fde00000 [disabled] [size=128K]
Capabilities: [48] Power Management version 2
Capabilities: [50] Vital Product Data <?>
Capabilities: [5c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+
Capabilities: [e0] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting <?>
Kernel driver in use: sky2
Kernel modules: sky2

02:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88E8052 PCI-E ASF Gigabit Ethernet Controller [11ab:4360] (rev 22)
Subsystem: Marvell Technology Group Ltd. Marvell RDK-8052 [11ab:5221]
Flags: bus master, fast devsel, latency 0, IRQ 1274
Memory at fddfc000 (64-bit, non-prefetchable) [size=16K]
I/O ports at ce00 [size=256]
[virtual] Expansion ROM at fdc00000 [disabled] [size=128K]
Capabilities: [48] Power Management version 2
Capabilities: [50] Vital Product Data <?>
Capabilities: [5c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+
Capabilities: [e0] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting <?>
Kernel driver in use: sky2
Kernel modules: sky2

03:00.0 RAID bus controller [0104]: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller [1095:3132] (rev 01)
Subsystem: Silicon Image, Inc. Unknown device [1095:7132]
Flags: bus master, fast devsel, latency 0, IRQ 18
Memory at fdbff000 (64-bit, non-prefetchable) [size=128]
Memory at fdbf8000 (64-bit, non-prefetchable) [size=16K]
I/O ports at bf00 [size=128]
[virtual] Expansion ROM at fda00000 [disabled] [size=512K]
Capabilities: [54] Power Management version 2
Capabilities: [5c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Capabilities: [70] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting <?>
Kernel driver in use: sata_sil24
Kernel modules: sata_sil24

04:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV630 [Radeon HD 2600XT] [1002:9588] (prog-if 00 [VGA controller])
Subsystem: PC Partner Limited Unknown device [174b:2e42]
Flags: bus master, fast devsel, latency 0, IRQ 19
Memory at d0000000 (64-bit, prefetchable) [size=256M]
Memory at fd9e0000 (64-bit, non-prefetchable) [size=64K]
I/O ports at ee00 [size=256]
[virtual] Expansion ROM at fd900000 [disabled] [size=128K]
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Capabilities: [100] Vendor Specific Information <?>
Kernel driver in use: fglrx_pci
Kernel modules: fglrx

04:00.1 Audio device [0403]: ATI Technologies Inc RV630/M76 audio device [Radeon HD 2600 Series] [1002:aa08]
Subsystem: PC Partner Limited Unknown device [174b:aa08]
Flags: bus master, fast devsel, latency 0, IRQ 5
Memory at fd9fc000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Capabilities: [100] Vendor Specific Information <?>

05:08.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. IEEE 1394 Host Controller [1106:3044] (rev 80) (prog-if 10 [OHCI])
Subsystem: DFI Inc Unknown device [15bd:1006]
Flags: bus master, stepping, medium devsel, latency 64, IRQ 23
Memory at fd7ff000 (32-bit, non-prefetchable) [size=2K]
I/O ports at af00 [size=128]
Capabilities: [50] Power Management version 2
Kernel driver in use: firewire_ohci
Kernel modules: firewire-ohci

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

#4 lore raw
In reply to Achim Gottinger
Quoted 6 lines · achim

Hi Jean and Pavel,

Thank you for the fast replies.

I run debian lenny 64bit which comes with sensors version 3.0.1. The debian package version is 3.0.1-5.

OK, so you have an up-to-date version of sensors-detect which only probes the I2C addresses it has to.

Quoted 1 line

The board has no special overclocking chip.

How do you know? If probing the SMBus did something bad to your hardware, then there has to be some special chip on the SMBus.

Of course, it can also be that your hardware just happened to die when you ran sensors-detect but it was only a coincidence. To say the truth, I'd be very happy if that was the case.

Quoted 9 lines

It comes with an 8-pin
connector for the 12V rails so the cpu can use up to 36A and therefore has more headroom for overclocking at my settings the cpu used max 11-12A. (I have an Gigabyte Odin PSU with monitoring software whom shows the power usage of the single rails and tested this issue before). Also it has few more memory settings and allows to adjust the cpu and nb voltage in steps ov 0.0625V. Those features make it overclockers first choice.

Quoted 7 lines

The cpu was abit overclocked while i ran sensors-detect. I used an 13.5 cpu multi instead of an 12.5 multi and had uppdet the cpu voltage from 1.3V to 1.3125V. Everything else was at stock.
Before I ran sensors-detect I ran the phoronix-test-suite for benchmarking purpose whom showed no problems. Normaly one of the cores stopps responding if I overclock the system too far, that did not happen before at 2.7GHz, it started at around 2.8GHz.

I take it that you had already tried higher overclocking settings on your CPU. Honestly, I can't say I am surprised when hardware dies after being overclocked. That's a risk you take when overclocking.

Quoted 1 line

I have not yet contacted Sapphire. The board however is a clone of the

Please contact them. If nothing else, they should be aware that they (presumably) use a chip which causes trouble. If users report about the problem, maybe they can find a better chip / safer design in their next products.

Quoted 1 line

DFI Lanparty UT790FX. On an overclocker forum I found an user report

Reminds me of this bug:
http://bugzilla.kernel.org/show_bug.cgi?idX89
The DFI Lanparty NF4 SLI Expert had an unknown chip at 0x2e which rebooted the system when probed. I can only guess that your board has a similar chip, except that the effects of probing are worse.

Quoted 11 lines

whom had a similar problem. In his case speedfan caused his board/cpu not to post. He contacted DFI and they said it can be that lower io access can cripple the bios. There are other users on that forum whom reported similar issues after starting sandra or evereset. Sometimes it is the bios getting corrupted sometimes it's the cpu getting stuck at C1 stage during post. Sometimes it helps to cool down the cpu below zero and it posts back. In other cases it helped to use DDR2-800 ram instead of DDR2-1066 ram. I tried to reflash the bios and cleared the cmos and dmi area but it did not help. I also tried to use DDR2-800 memory without luck. I can sort out a crippled bios in my case bcause the board still works fine with an 9600BE.

And you also said that the original CPU no longer works on a different motherboard. So indeed it smells like a dead CPU rather than BIOS issues.

Quoted 2 lines

The board uses the ITC8716F-S chip and the it87 module works fine if i

I guess it's a typo and you mean IT8716F-S.

Quoted 10 lines

load it manual. I'd like to look a little deeper into that sensor chip reading issues so i'll start to read the source code now to find out what happens. I attached the dmidecode and the lspci -nnv output.

---------- kenrel log output of the it87 module ----------------
it87: Found IT8716F chip at 0x228, revision 3
it87: in3 is VCC (+5V)
it87: in7 is VCCH (+5V Stand-By)
hwmon-vid: Unknown VRM version of your x86 CPU
----------------------------------------------------------------

What's wrong with the it87 driver?

The good news is that the motherboard DMI data is present:

Base Board Information
Manufacturer: SAPPHIRE Inc.
Product Name: PC-AM2RD790

So we can blacklist it from i2c-piix4. I'll prepare a patch later today.

Signature · 6 lines
Jean Delvare

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

A message that is not in the archive (sent off-list or not yet received): [email protected]

#6 lore raw

PATCH 1/1 i2c-piix4: Blacklist the Sapphire AM2RD790 motherboard

Quoted 8 lines · Jean Delvare

The good news is that the motherboard DMI data is present:

Base Board Information
Manufacturer: SAPPHIRE Inc.
Product Name: PC-AM2RD790

So we can blacklist it from i2c-piix4. I'll prepare a patch later today.

Here you go. Would you have the possibility to test the patch below? You'll have to rebuild your kernel (or at least the i2c-piix4 driver) with this patch applied, then try loading the i2c-piix4 driver, you should see an error message in the logs and no i2c bus created.

* * * * *

We had a report that running sensors-detect on a Sapphire AM2RD790 motherbord killed the CPU. While the exact cause is still unknown, I'd rather play it safe and prevent any access to the SMBus on that machine by not letting the i2c-piix4 driver attach to the SMBus host device on that machine.

---
 drivers/i2c/busses/i2c-piix4.c |   25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)
drivers/i2c/busses/i2c-piix4.c +23 -2
@@ -108,7 +108,20 @@ static unsigned short piix4_smba;
 static struct pci_driver piix4_driver;
 static struct i2c_adapter piix4_adapter;
 
-static struct dmi_system_id __devinitdata piix4_dmi_table[] = {
+static struct dmi_system_id __devinitdata piix4_dmi_blacklist[] = {
+	{
+		.ident = "Sapphire AM2RD790",
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "SAPPHIRE Inc."),
+			DMI_MATCH(DMI_BOARD_NAME, "PC-AM2RD790"),
+		},
+	},
+	{ }
+};
+
+/* The IBM entry is in a separate table because we only check it
+   on Intel-based systems */
+static struct dmi_system_id __devinitdata piix4_dmi_ibm[] = {
 	{
 		.ident = "IBM",
 		.matches = { DMI_MATCH(DMI_SYS_VENDOR, "IBM"), },
@@ -123,8 +136,16 @@ static int __devinit piix4_setup(struct 
 
 	dev_info(&PIIX4_dev->dev, "Found %s device\n", pci_name(PIIX4_dev));
 
+	/* On some motherboards, it was reported that accessing the SMBus
+	   caused severe hardware problems */
+	if (dmi_check_system(piix4_dmi_blacklist)) {
+		dev_err(&PIIX4_dev->dev,
+			"Accessing the SMBus on this system is unsafe!\n");
+		return -EPERM;
+	}
+
 	/* Don't access SMBus on IBM systems which get corrupted eeproms */
-	if (dmi_check_system(piix4_dmi_table) &&
+	if (dmi_check_system(piix4_dmi_ibm) &&
 			PIIX4_dev->vendor == PCI_VENDOR_ID_INTEL) {
 		dev_err(&PIIX4_dev->dev, "IBM system detected; this module "
 			"may corrupt your serial eeprom! Refusing to load "
Signature · 6 lines
Jean Delvare

_______________________________________________
i2c mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/i2c

A message that is not in the archive (sent off-list or not yet received): [email protected]

#8 lore raw

PATCH 1/1 i2c-piix4: Blacklist two mainboards

We had a report that running sensors-detect on a Sapphire AM2RD790 motherbord killed the CPU. While the exact cause is still unknown, I'd rather play it safe and prevent any access to the SMBus on that machine by not letting the i2c-piix4 driver attach to the SMBus host device on that machine. Also blacklist a similar board made by DFI.

---
Updated to also blacklist the DFI Lanparty UT 790FX, as it has the same issue.

 drivers/i2c/busses/i2c-piix4.c |   30 ++++++++++++++++++++++++++++--
 1 file changed, 28 insertions(+), 2 deletions(-)
drivers/i2c/busses/i2c-piix4.c +28 -2
@@ -108,7 +108,25 @@ static unsigned short piix4_smba;
 static struct pci_driver piix4_driver;
 static struct i2c_adapter piix4_adapter;
 
-static struct dmi_system_id __devinitdata piix4_dmi_table[] = {
+static struct dmi_system_id __devinitdata piix4_dmi_blacklist[] = {
+	{
+		.ident = "Sapphire AM2RD790",
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "SAPPHIRE Inc."),
+			DMI_MATCH(DMI_BOARD_NAME, "PC-AM2RD790"),
+		},
+		.ident = "DFI Lanparty UT 790FX",
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "DFI Inc."),
+			DMI_MATCH(DMI_BOARD_NAME, "LP UT 790FX"),
+		},
+	},
+	{ }
+};
+
+/* The IBM entry is in a separate table because we only check it
+   on Intel-based systems */
+static struct dmi_system_id __devinitdata piix4_dmi_ibm[] = {
 	{
 		.ident = "IBM",
 		.matches = { DMI_MATCH(DMI_SYS_VENDOR, "IBM"), },
@@ -123,8 +141,16 @@ static int __devinit piix4_setup(struct 
 
 	dev_info(&PIIX4_dev->dev, "Found %s device\n", pci_name(PIIX4_dev));
 
+	/* On some motherboards, it was reported that accessing the SMBus
+	   caused severe hardware problems */
+	if (dmi_check_system(piix4_dmi_blacklist)) {
+		dev_err(&PIIX4_dev->dev,
+			"Accessing the SMBus on this system is unsafe!\n");
+		return -EPERM;
+	}
+
 	/* Don't access SMBus on IBM systems which get corrupted eeproms */
-	if (dmi_check_system(piix4_dmi_table) &&
+	if (dmi_check_system(piix4_dmi_ibm) &&
 			PIIX4_dev->vendor == PCI_VENDOR_ID_INTEL) {
 		dev_err(&PIIX4_dev->dev, "IBM system detected; this module "
 			"may corrupt your serial eeprom! Refusing to load "
Signature · 6 lines
Jean Delvare

_______________________________________________
i2c mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/i2c

A message that is not in the archive (sent off-list or not yet received): [email protected]

#10 lore raw

Re: [PATCH] i2c-piix4: Blacklist two mainboards

We had a report that running sensors-detect on a Sapphire AM2RD790 motherbord killed the CPU. While the exact cause is still unknown, I'd rather play it safe and prevent any access to the SMBus on that machine by not letting the i2c-piix4 driver attach to the SMBus host device on that machine. Also blacklist a similar board made by DFI.

---
Once again... I forgot to refresh the patch before sending it, sorry.

 drivers/i2c/busses/i2c-piix4.c |   32 ++++++++++++++++++++++++++++++--
 1 file changed, 30 insertions(+), 2 deletions(-)
drivers/i2c/busses/i2c-piix4.c +30 -2
@@ -108,7 +108,27 @@ static unsigned short piix4_smba;
 static struct pci_driver piix4_driver;
 static struct i2c_adapter piix4_adapter;
 
-static struct dmi_system_id __devinitdata piix4_dmi_table[] = {
+static struct dmi_system_id __devinitdata piix4_dmi_blacklist[] = {
+	{
+		.ident = "Sapphire AM2RD790",
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "SAPPHIRE Inc."),
+			DMI_MATCH(DMI_BOARD_NAME, "PC-AM2RD790"),
+		},
+	},
+	{
+		.ident = "DFI Lanparty UT 790FX",
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "DFI Inc."),
+			DMI_MATCH(DMI_BOARD_NAME, "LP UT 790FX"),
+		},
+	},
+	{ }
+};
+
+/* The IBM entry is in a separate table because we only check it
+   on Intel-based systems */
+static struct dmi_system_id __devinitdata piix4_dmi_ibm[] = {
 	{
 		.ident = "IBM",
 		.matches = { DMI_MATCH(DMI_SYS_VENDOR, "IBM"), },
@@ -123,8 +143,16 @@ static int __devinit piix4_setup(struct 
 
 	dev_info(&PIIX4_dev->dev, "Found %s device\n", pci_name(PIIX4_dev));
 
+	/* On some motherboards, it was reported that accessing the SMBus
+	   caused severe hardware problems */
+	if (dmi_check_system(piix4_dmi_blacklist)) {
+		dev_err(&PIIX4_dev->dev,
+			"Accessing the SMBus on this system is unsafe!\n");
+		return -EPERM;
+	}
+
 	/* Don't access SMBus on IBM systems which get corrupted eeproms */
-	if (dmi_check_system(piix4_dmi_table) &&
+	if (dmi_check_system(piix4_dmi_ibm) &&
 			PIIX4_dev->vendor == PCI_VENDOR_ID_INTEL) {
 		dev_err(&PIIX4_dev->dev, "IBM system detected; this module "
 			"may corrupt your serial eeprom! Refusing to load "
Signature · 6 lines
Jean Delvare

_______________________________________________
i2c mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/i2c
author
#11 lore raw
In reply to Achim Gottinger

Am Samstag, den 03.05.2008, 18:27 +0200 schrieb Jean Delvare:

Quoted 8 lines · achim
Quoted 6 lines

Hi Jean and Pavel,

Thank you for the fast replies.

I run debian lenny 64bit which comes with sensors version 3.0.1. The debian package version is 3.0.1-5.

Quoted 8 lines

OK, so you have an up-to-date version of sensors-detect which only probes the I2C addresses it has to.

Quoted 1 line

The board has no special overclocking chip.

How do you know? If probing the SMBus did something bad to your hardware, then there has to be some special chip on the SMBus.

You are right i can not sort that out just by looking at the bios options.

Quoted 8 lines

Of course, it can also be that your hardware just happened to die when you ran sensors-detect but it was only a coincidence. To say the truth, I'd be very happy if that was the case.

I take it that you had already tried higher overclocking settings on your CPU. Honestly, I can't say I am surprised when hardware dies after being overclocked. That's a risk you take when overclocking.

To sort out overclocking issues i mounted an X25000BE and ran sensors-detect.
Again the system froze at

Next adapter PIIX4 at 0b00

Fortunately the X2 cpu is still working.

For the record with the 9600BE the i2c_piix4 and the it87 modules work without issues (some sensor readings are labled wrong, but that's an other story whom i can fix by editin sensors.conf i guess).

I read the bugreport and ran

i2cdetect -l and i2cdetec 0

Both runs did not freeze the system.

---------------------------- Output ---------------------------------

debian-9850:/home/achim# i2cdetect 0
WARNING! This program can confuse your I2C bus, cause data loss and
worse!
I will probe file /dev/i2c-0.
I will probe address range 0x03-0x77.
Continue? [Y/n] 
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 2e -- 
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 4e -- 
50: -- -- 52 53 -- -- -- 57 -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 6e -- 
70: 70 -- -- -- -- -- -- --                         
debian-9850:/home/achim# i2cdetect -l
i2c-0	smbus     	SMBus PIIX4 adapter at 0b00     	SMBus adapter
---------------------------- Output ---------------------------------

I'll try i2cdump 0 0x2e now and will also try the other adresses to track down the problem.

Quoted 4 lines

Please contact them. If nothing else, they should be aware that they (presumably) use a chip which causes trouble. If users report about the problem, maybe they can find a better chip / safer design in their next products.

The board is the same as the DFI one just rebranded, DFI is aware of those issues. But I'll inform the Sapphire support as well.

Quoted 3 lines

I guess it's a typo and you mean IT8716F-S.

Yepp, typo

Quoted 5 lines
Quoted 5 lines

load it manual. I'd like to look a little deeper into that sensor chip reading issues so i'll start to read the source code now to find out what happens. I attached the dmidecode and the lspci -nnv output.

Quoted 8 lines
Quoted 6 lines

---------- kenrel log output of the it87 module ----------------
it87: Found IT8716F chip at 0x228, revision 3
it87: in3 is VCC (+5V)
it87: in7 is VCCH (+5V Stand-By)
hwmon-vid: Unknown VRM version of your x86 CPU
----------------------------------------------------------------

What's wrong with the it87 driver?

Nothing I was just unsure what module caused the freeze.

Quoted 9 lines

The good news is that the motherboard DMI data is present:

Base Board Information
Manufacturer: SAPPHIRE Inc.
Product Name: PC-AM2RD790

So we can blacklist it from i2c-piix4. I'll prepare a patch later today.

Thank you, I think that info changes if I use an DFI bios. Looks like the info is the same which CPU-Z shows on the motherboard page I might have an screenshot with the DFI info here also.

PS: Sorry for the double posts i'm to fast with the reply button here.

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

#12 lore raw
In reply to Achim Gottinger
Quoted 5 lines · achim

Am Samstag, den 03.05.2008, 18:27 +0200 schrieb Jean Delvare:

Quoted 3 lines

I take it that you had already tried higher overclocking settings on your CPU. Honestly, I can't say I am surprised when hardware dies after being overclocked. That's a risk you take when overclocking.

Quoted 7 lines

To sort out overclocking issues i mounted an X25000BE and ran sensors-detect.
Again the system froze at

Next adapter PIIX4 at 0b00

Fortunately the X2 cpu is still working.

I don't think that this rules out overclocking. The overclocked CPU died, the non-overclocked one froze but is still alive. If nothing else, it suggests that the overclocked CPU was more fragile against whatever happened.

Quoted 3 lines

For the record with the 9600BE the i2c_piix4 and the it87 modules work without issues (some sensor readings are labled wrong, but that's an other story whom i can fix by editin sensors.conf i guess).

Note that the i2c-piix4 driver doesn't do anything by itself.

Quoted 18 lines

I read the bugreport and ran

i2cdetect -l and i2cdetec 0

Both runs did not freeze the system.

---------------------------- Output ---------------------------------

debian-9850:/home/achim# i2cdetect 0
WARNING! This program can confuse your I2C bus, cause data loss and
worse!
I will probe file /dev/i2c-0.
I will probe address range 0x03-0x77.
Continue? [Y/n] 
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 2e -- 
Quoted 8 lines
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 4e -- 
50: -- -- 52 53 -- -- -- 57 -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 6e -- 
70: 70 -- -- -- -- -- -- --                         
debian-9850:/home/achim# i2cdetect -l
i2c-0	smbus     	SMBus PIIX4 adapter at 0b00     	SMBus adapter
---------------------------- Output ---------------------------------  

Looks a lot like that older bug report I mentioned where probing address 0x2e rebooted the machine. Probably designed by the same person, using the same or similar chip.

Quoted 3 lines

I'll try i2cdump 0 0x2e now and will also try the other adresses to track down the problem.

I expect i2cdump 0 0x2e will freeze your system if not worse. Most likely, sensors-detect would complete if you skipped address 0x2e on SMBus probe. At least that was the case for the other bug report.

Quoted 11 lines
Quoted 7 lines

The good news is that the motherboard DMI data is present:

Base Board Information
Manufacturer: SAPPHIRE Inc.
Product Name: PC-AM2RD790

So we can blacklist it from i2c-piix4. I'll prepare a patch later today..

Thank you, I think that info changes if I use an DFI bios. Looks like the info is the same which CPU-Z shows on the motherboard page I might have an screenshot with the DFI info here also.

In general, people using a BIOS which was not meant for their motherboard should know that they are doing something wrong and should be ready to face the consequences. That being said, it would be easy enough to blacklist this other motherboard as well, presumably it has the same problems. Can you provide the dmidecode information for the DFI board / BIOS?

Signature · 6 lines
Jean Delvare

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
#13 lore raw
In reply to Achim Gottinger
Quoted 26 lines · Jean Delvare
Quoted 11 lines · achim

---------------------------- Output ---------------------------------

debian-9850:/home/achim# i2cdetect 0
WARNING! This program can confuse your I2C bus, cause data loss and
worse!
I will probe file /dev/i2c-0.
I will probe address range 0x03-0x77.
Continue? [Y/n] 
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 2e -- 
Quoted 8 lines
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 4e -- 
50: -- -- 52 53 -- -- -- 57 -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 6e -- 
70: 70 -- -- -- -- -- -- --                         
debian-9850:/home/achim# i2cdetect -l
i2c-0	smbus     	SMBus PIIX4 adapter at 0b00     	SMBus adapter
---------------------------- Output ---------------------------------  

Looks a lot like that older bug report I mentioned where probing address 0x2e rebooted the machine. Probably designed by the same person, using the same or similar chip.

Quoted 1 line
Quoted 6 lines
Quoted 2 lines

I'll try i2cdump 0 0x2e now and will also try the other adresses to track down the problem.

I expect i2cdump 0 0x2e will freeze your system if not worse. Most likely, sensors-detect would complete if you skipped address 0x2e on SMBus probe. At least that was the case for the other bug report.

In fact I would be more interested in a dump of 0x4e. The other report had a chip there too, I wonder if it could be the same chip as the one at 0x2e (and maybe 0x6e? The other report didn't have that.) If we could identify the device by reading from 0x4e, we could skip the probe of 0x2e and that would hopefully solve the problem. But this will be very difficult to identify the device as long as we don't know what device it is. That's where the help of DFI or Sapphire would be valuable.

Signature · 6 lines
Jean Delvare

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
author
#14 lore raw
In reply to Achim Gottinger

Am Samstag, den 03.05.2008, 21:27 +0200 schrieb Jean Delvare:

Quoted 34 lines · Jean Delvare
Quoted 26 lines · achim
Quoted 11 lines

---------------------------- Output ---------------------------------

debian-9850:/home/achim# i2cdetect 0
WARNING! This program can confuse your I2C bus, cause data loss and
worse!
I will probe file /dev/i2c-0.
I will probe address range 0x03-0x77.
Continue? [Y/n] 
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 2e -- 
Quoted 8 lines
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 4e -- 
50: -- -- 52 53 -- -- -- 57 -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 6e -- 
70: 70 -- -- -- -- -- -- --                         
debian-9850:/home/achim# i2cdetect -l
i2c-0	smbus     	SMBus PIIX4 adapter at 0b00     	SMBus adapter
---------------------------- Output ---------------------------------  

Looks a lot like that older bug report I mentioned where probing address 0x2e rebooted the machine. Probably designed by the same person, using the same or similar chip.

Quoted 1 line
Quoted 6 lines
Quoted 2 lines

I'll try i2cdump 0 0x2e now and will also try the other adresses to track down the problem.

I expect i2cdump 0 0x2e will freeze your system if not worse. Most likely, sensors-detect would complete if you skipped address 0x2e on SMBus probe. At least that was the case for the other bug report.

Quoted 9 lines

In fact I would be more interested in a dump of 0x4e. The other report had a chip there too, I wonder if it could be the same chip as the one at 0x2e (and maybe 0x6e? The other report didn't have that.) If we could identify the device by reading from 0x4e, we could skip the probe of 0x2e and that would hopefully solve the problem. But this will be very difficult to identify the device as long as we don't know what device it is. That's where the help of DFI or Sapphire would be valuable.

I tried the dump of 0x2e and the system froze. I'm glad it boot's without problems with the X2 cpu.
However I could make a dump of 0x4e and 0x6e. ------------------------------------------------------------------------ i2cdump 0 0x4e
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x4e, mode byte Continue? [Y/n]

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 02 00 00 00 3f 00 00 00 00 00 00 00 00 00 00 00    ?...?...........
10: 00 00 ff 0f 00 00 00 00 00 00 00 00 00 00 00 00    ...?............
20: 00 00 00 00 00 00 00 00 83 12 12 28 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 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: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

------------------------------------------------------------------------ #i2cdump 0 0x6e
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x6e, mode byte Continue? [Y/n]

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07    ????????????????
10: 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07    ????????????????
20: 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07    ????????????????
30: 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07    ????????????????
40: 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07    ????????????????
50: 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07    ????????????????
60: 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07    ????????????????
70: 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07    ????????????????
80: 07 ff 00 40 31 43 07 00 00 00 80 00 00 00 00 dd    ?..@1C?...?....?
90: dd dd dd dd dd dd dd dd dd dd dd dd dd dd XX XX    ??????????????XX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX

------------------------------------------------------------------------

I spotted one odd thin. As i ran the dump of 0x6e the first time it stuck for a few seconds at around the line starting with 90. since then both dumps look like this:

------------------------------------------------------------------------

debian-9850:/home/achim# i2cdump 0 0x4e 
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and
worse!
I will probe file /dev/i2c-0, address 0x4e, mode byte
Continue? [Y/n] 
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
debian-9850:/home/achim# i2cdump 0 0x6e 
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and
worse!
I will probe file /dev/i2c-0, address 0x6e, mode byte
Continue? [Y/n] 
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
------------------------------------------------------------------------

I'll try a different version of the Sapphire bios now and then the DFI bios.
I like overclocking and a dead cpu is something i estimate every now and then due to that. Phenoms however tend to stop working more or less out of the blue, in many cases the systems freeze after starting tools like everest, speedfan, sandra or even cpu-z. Sometimes a bios reflash helps sometimes the cpu is non functional afterwards. Having that io access problem tracked down is really exciting and I appreciate your support.

achim~

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

#15 lore raw
In reply to Achim Gottinger

Hallo Achim,

Quoted 27 lines · achim

I tried the dump of 0x2e and the system froze. I'm glad it boot's without problems with the X2 cpu.
However I could make a dump of 0x4e and 0x6e. ------------------------------------------------------------------------ i2cdump 0 0x4e
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x4e, mode byte Continue? [Y/n]

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 02 00 00 00 3f 00 00 00 00 00 00 00 00 00 00 00    ?...?...........
10: 00 00 ff 0f 00 00 00 00 00 00 00 00 00 00 00 00    ...?............
20: 00 00 00 00 00 00 00 00 83 12 12 28 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 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: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
Quoted 1 line

------------------------------------------------------------------------

Very interesting, it looks very similar to the dump at:
http://bugzilla.kernel.org/show_bug.cgi?idX89#c18
This really has to be the same chip. If we knew what chip it is and if that chip has some read-only registers will well-defined value, we could check 0x4e first and blacklist 0x2e if we recognize the chip. Registers 0x28-0x2b look promising, but without a datasheet I just can't tell if we can reliably use them for identification purposes.

Quoted 69 lines

#i2cdump 0 0x6e
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x6e, mode byte Continue? [Y/n]

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07    ????????????????
10: 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07    ????????????????
20: 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07    ????????????????
30: 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07    ????????????????
40: 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07    ????????????????
50: 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07    ????????????????
60: 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07    ????????????????
70: 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07    ????????????????
80: 07 ff 00 40 31 43 07 00 00 00 80 00 00 00 00 dd    ?..@1C?...?....?
90: dd dd dd dd dd dd dd dd dd dd dd dd dd dd XX XX    ??????????????XX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX

------------------------------------------------------------------------

I spotted one odd thin. As i ran the dump of 0x6e the first time it stuck for a few seconds at around the line starting with 90. since then both dumps look like this:

------------------------------------------------------------------------

debian-9850:/home/achim# i2cdump 0 0x4e 
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and
worse!
I will probe file /dev/i2c-0, address 0x4e, mode byte
Continue? [Y/n] 
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
debian-9850:/home/achim# i2cdump 0 0x6e 
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and
worse!
I will probe file /dev/i2c-0, address 0x6e, mode byte
Continue? [Y/n] 
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
Quoted 8 lines
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
------------------------------------------------------------------------

Basically the SMBus is stuck. Could be because you accessed the chip at 0x6e in a way it didn't expect and didn't like (in this case, reading from register 0x9e). I wonder how reproducible it is. Most probably, you have to reboot before the SMBus will work again. It might even require a cold boot.

Quoted 8 lines

I'll try a different version of the Sapphire bios now and then the DFI bios.
I like overclocking and a dead cpu is something i estimate every now and then due to that. Phenoms however tend to stop working more or less out of the blue, in many cases the systems freeze after starting tools like everest, speedfan, sandra or even cpu-z. Sometimes a bios reflash helps sometimes the cpu is non functional afterwards. Having that io access problem tracked down is really exciting and I appreciate your support.

I expected you to be much more angry about losing a brand new CPU... I'd like to fix the problem so that other users don't experience the same. Even if the CPU doesn't die, freezing your machine when running a script is no good. Even if I consider that the motherboard manufacturer is to blame for using dangerous chips or designs, let's still try to prevent the problem from happening too frequently.

Signature · 6 lines
Jean Delvare

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
author
#16 lore raw
In reply to Achim Gottinger
Quoted 5 lines

I don't think that this rules out overclocking. The overclocked CPU died, the non-overclocked one froze but is still alive. If nothing else, it suggests that the overclocked CPU was more fragile against whatever happened.

It sorted out the coincidence theory. I agree with you that the overclocked cpu was more fragile. I spotted a week ago that the cpu was not as robust as at the beginning.While inspecting the capabilities of the northbridge I ran stability testings for about ~30hrs with northbridge voltages at around 1.4V (1.3V is stock). After that the system was no longer stable at 2.8GHz with 1.3125V (1.3V stock). Going back to 2.7GHz fixed the stability issues. I ran this for at least a days without any problems till it froze. It was just a coincidence that i used lm-sensors and not typical windows monitoring tools.

Quoted 4 lines

Looks a lot like that older bug report I mentioned where probing address 0x2e rebooted the machine. Probably designed by the same person, using the same or similar chip.

Exactly in oposite to the user of the DFI Lanparty board with the nvidia chipset i get no hangups when i load the it87 module manual without parameters excluding 0x2e.

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines

The good news is that the motherboard DMI data is present:

Base Board Information
Manufacturer: SAPPHIRE Inc.
Product Name: PC-AM2RD790

Quoted 9 lines
Quoted 1 line
Quoted 1 line

So we can blacklist it from i2c-piix4. I'll prepare a patch later today..

In general, people using a BIOS which was not meant for their motherboard should know that they are doing something wrong and should be ready to face the consequences. That being said, it would be easy enough to blacklist this other motherboard as well, presumably it has the same problems. Can you provide the dmidecode information for the DFI board / BIOS?

Other already tried to flash the dfi bios on the sapphire board and i also used it for weeks because the bios the board was shipped with had all type of issues.
So I switched to the latest stable DFI bios and attached a dmidecode dump here.
I also tried i2cdump at 0x4e and 0x6e.
Same results as with the sapphire bios. Again the 0x6e dump stopped at 0x9e and outputs only XX till i reboot, a reload of the i2c-piix4 module does not help here.

# dmidecode 2.9
SMBIOS 2.5 present.
54 structures occupying 2274 bytes.
Table at 0x000F0000.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: Phoenix Technologies, LTD
Version: 6.00 PG
Release Date: 04/16/2008
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 1024 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
LS-120 boot is supported
ATAPI Zip drive boot is supported
BIOS boot specification is supported

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Unknow
Product Name: Unknow
Version: Unknow
Serial Number: Unknow
UUID: Not Present
Wake-up Type: Power Switch
SKU Number:
Family:

Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: DFI Inc.
Product Name: LP UT 790FX
Version: 1.0
Serial Number:

Handle 0x0003, DMI type 3, 17 bytes
Chassis Information
Manufacturer: Unknow
Type: Desktop
Lock: Not Present
Version: Unknow
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, 40 bytes
Processor Information
Socket Designation: Socket AM2
Type: Central Processor
Family: Athlon 64 X2
Manufacturer: AMD
ID: B2 0F 06 00 FF FB 8B 17
Signature: Family 15, Model 107, Stepping 2 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) 64 X2 Dual Core Processor 5000+
Voltage: 1.3 V
External Clock: 200 MHz
Max Speed: 3000 MHz
Current Speed: 2600 MHz
Status: Populated, Enabled
Upgrade: Socket 940
L1 Cache Handle: 0x000A
L2 Cache Handle: 0x000B
L3 Cache Handle: Not Provided
Serial Number:
Asset Tag:
Part Number:
Core Count: 2
Core Enabled: 2
Thread Count: 2
Characteristics:
64-bit capable

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: 4096 MB Maximum Total Memory Size: 16384 MB Supported Speeds:
70 ns
60 ns
50 ns
Supported Memory Types:
Standard
DIMM
Memory Module Voltage: 2.9 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: None
Current Speed: Unknown
Type: Other Unknown EDO
Installed Size: Not Installed
Enabled Size: Not Installed
Error Status: OK

Handle 0x0007, DMI type 6, 12 bytes
Memory Module Information
Socket Designation: A1
Bank Connections: None
Current Speed: Unknown
Type: Other Unknown EDO
Installed Size: Not Installed
Enabled Size: Not Installed
Error Status: OK

Handle 0x0008, DMI type 6, 12 bytes
Memory Module Information
Socket Designation: A2
Bank Connections: 4 5
Current Speed: Unknown
Type: Other Unknown EDO
Installed Size: 1024 MB (Double-bank Connection) Enabled Size: 1024 MB (Double-bank Connection) Error Status: OK

Handle 0x0009, DMI type 6, 12 bytes
Memory Module Information
Socket Designation: A3
Bank Connections: None
Current Speed: Unknown
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: 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 0x000C, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: PRIMARY IDE Internal Connector Type: On Board IDE External Reference Designator: Not Specified External Connector Type: None
Port Type: Other

Handle 0x000D, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: FDD Internal Connector Type: On Board Floppy External Reference Designator: Not Specified External Connector Type: None
Port Type: 8251 FIFO Compatible

Handle 0x000E, 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 0x000F, 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 0x0010, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Keyboard
Internal Connector Type: PS/2
External Reference Designator:
External Connector Type: PS/2
Port Type: Keyboard Port

Handle 0x0011, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: PS/2 Mouse
Internal Connector Type: PS/2
External Reference Designator:
External Connector Type: PS/2
Port Type: Mouse Port

Handle 0x0012, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB0 External Connector Type: Other
Port Type: USB

Handle 0x0013, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB1 External Connector Type: Other
Port Type: USB

Handle 0x0014, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB2 External Connector Type: Other
Port Type: USB

Handle 0x0015, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB3 External Connector Type: Other
Port Type: USB

Handle 0x0016, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB4 External Connector Type: Other
Port Type: USB

Handle 0x0017, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB5 External Connector Type: Other
Port Type: USB

Handle 0x0018, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB6 External Connector Type: Other
Port Type: USB

Handle 0x0019, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB7 External Connector Type: Other
Port Type: USB

Handle 0x001A, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB8 External Connector Type: Other
Port Type: USB

Handle 0x001B, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Specified Internal Connector Type: None External Reference Designator: USB9 External Connector Type: Other
Port Type: USB

Handle 0x001C, DMI type 9, 13 bytes
System Slot Information
Designation: PCI0
Type: 32-bit PCI
Current Usage: Available
Length: Long
ID: 1
Characteristics:
5.0 V is provided
PME signal is supported

Handle 0x001D, DMI type 9, 13 bytes
System Slot Information
Designation: PCI1
Type: 32-bit PCI
Current Usage: Available
Length: Long
ID: 2
Characteristics:
5.0 V is provided
PME signal is supported

Handle 0x001E, DMI type 9, 13 bytes
System Slot Information
Designation: PCI2
Type: 32-bit PCI
Current Usage: Available
Length: Long
ID: 3
Characteristics:
5.0 V is provided
PME signal is supported

Handle 0x001F, DMI type 9, 13 bytes
System Slot Information
Designation: PCI3
Type: 32-bit PCI
Current Usage: Available
Length: Long
ID: 4
Characteristics:
5.0 V is provided
PME signal is supported

Handle 0x0020, DMI type 9, 13 bytes
System Slot Information

	Designation: PCI-X
	Type: 32-bit PCI-X
	Current Usage: Available
	Length: Long
	ID: 1
	Characteristics:
		5.0 V is provided

Handle 0x0021, DMI type 9, 13 bytes
System Slot Information

	Designation: PCI-X
	Type: 32-bit PCI-X
	Current Usage: Available
	Length: Long
	ID: 232
	Characteristics:
		5.0 V is provided

Handle 0x0022, DMI type 9, 13 bytes
System Slot Information

	Designation: PCI-X
	Type: 32-bit PCI-X
	Current Usage: Available
	Length: Long
	ID: 7
	Characteristics:
		5.0 V is provided

Handle 0x0023, DMI type 9, 13 bytes
System Slot Information

	Designation: PCI-X
	Type: 32-bit PCI-X
	Current Usage: Available
	Length: Long
	ID: 235
	Characteristics:
		5.0 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: No Module Installed
Form Factor: DIMM
Set: None
Locator: A0
Bank Locator: Bank0/1
Type: DDR2
Type Detail: None
Speed: 2048 MHz (0.5 ns)
Manufacturer: <BAD INDEX>
Serial Number: Not Specified
Asset Tag: None
Part Number: None

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: No Module Installed
Form Factor: DIMM
Set: None
Locator: A1
Bank Locator: Bank2/3
Type: DDR2
Type Detail: None
Speed: 2048 MHz (0.5 ns)
Manufacturer: <BAD INDEX>
Serial Number: Not Specified
Asset Tag: None
Part Number: None

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: 1024 MB
Form Factor: DIMM
Set: None
Locator: A2
Bank Locator: Bank4/5
Type: DDR2
Type Detail: None
Speed: 2048 MHz (0.5 ns)
Manufacturer: <BAD INDEX>
Serial Number: Not Specified
Asset Tag: None
Part Number: None

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: DDR2
Type Detail: None
Speed: 2048 MHz (0.5 ns)
Manufacturer: <BAD INDEX>
Serial Number: Not Specified
Asset Tag: None
Part Number: None

Handle 0x002A, DMI type 19, 15 bytes
Memory Array Mapped Address

	Starting Address: 0x00000000000
	Ending Address: 0x0103FFFFFFF
	Range Size: 65 GB
	Physical Array Handle: 0x0025
	Partition Width: 0

Handle 0x002B, DMI type 20, 19 bytes
Memory Device Mapped Address

	Starting Address: 0x00000000000
	Ending Address: 0x000000003FF
	Range Size: 1 kB
	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: 0x00000000000
	Ending Address: 0x000000003FF
	Range Size: 1 kB
	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: 0x01000000000
	Ending Address: 0x0003FFFFFFF
	Range Size: 4033 GB
	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 11, 5 bytes
OEM Strings
String 1:

Handle 0x0031, DMI type 188, 212 bytes
OEM-specific Type

	Header and Data:
		BC D4 31 00 00 00 00 80 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 7F 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 03 00 EB 02 00 AE
		00 00 00 00 00 00 00 00 01 00 00 00 01 01 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 E0 3E 78 00 00 00 00 00 00 00 00 00
		46 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00
		24 F2 7D AE 20 13 82 20 10 08 01 00 7B 00 10 74
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00

Handle 0x0032, DMI type 190, 212 bytes
OEM-specific Type

	Header and Data:
		BE D4 32 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 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 192, 244 bytes
OEM-specific Type

	Header and Data:
		C0 F4 33 00 15 14 15 16 16 15 15 14 15 00 00 00
		14 13 14 13 12 12 12 13 14 00 00 00 00 40 00 00
		15 15 16 17 16 15 15 16 15 14 12 13 13 13 14 13
		14 14 00 38 00 00 22 32 11 20 20 25 20 10 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 0x0034, DMI type 194, 244 bytes
OEM-specific Type

	Header and Data:
		C2 F4 34 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 00 00 00 00 00 00 00 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 0x0035, DMI type 127, 4 bytes
End Of Table

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

#17 lore raw
In reply to Achim Gottinger

I took a picture of the board and numbered the chips.
http://www.abload.de/image.php?img=img_6532l9j.jpg

Chip 1-2 are the two NIC chips. Chip three is interesting. It was hard to read but i found that chip ICS9LPRS477BKL

I found that article later explaining that chip as an clock generator.
http://www.planet3dnow.de/vbulletin/showthread.php?t30028&garpg=6

Here are specs for a chip with an very similar number which is a clock generator chip.
http://www.idt.com/?genID=9LPRS478

Chip four is something like ICS 7714084. The five chips with number five have a lable like PI2PCIE.
Chip 8 is the via firewire controller, number nine is the sensor chip and ten seems to be an ST75185C like RS-232 driver and receiver chip rellated to the com port connector next to him.

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

#18 lore raw
In reply to Achim Gottinger

Hi Achim,

Quoted 6 lines · Achim Gottinger

I took a picture of the board and numbered the chips.
http://www.abload.de/image.php?img=img_6532l9j.jpg

Chip 1-2 are the two NIC chips. Chip three is interesting. It was hard to read but i found that chip ICS9LPRS477BKL

Quoted 6 lines

I found that article later explaining that chip as an clock generator.
http://www.planet3dnow.de/vbulletin/showthread.php?t30028&garpg=6

Here are specs for a chip with an very similar number which is a clock generator chip.
http://www.idt.com/?genID=9LPRS478

There's also this one:
http://www.idt.com/?genID=9LPRS471

Maybe you misread the last 1 as a 7?

Both chips have an SMBus interface so most certainly at least one of the addresses of i2cdetect corresponds to this chip. We'd need a datasheet but it doesn't seem to be available for download :(

Quoted 2 lines

Chip four is something like ICS 7714084.

Couldn't find anything about this one.

Quoted 5 lines

The five chips with number five
have a lable like PI2PCIE.
Chip 8 is the via firewire controller, number nine is the sensor chip and ten seems to be an ST75185C like RS-232 driver and receiver chip rellated to the com port connector next to him.

Signature · 6 lines
Jean Delvare

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
#19 lore raw
In reply to Achim Gottinger
Quoted 6 lines · achim
Quoted 4 lines

I don't think that this rules out overclocking. The overclocked CPU died, the non-overclocked one froze but is still alive. If nothing else, it suggests that the overclocked CPU was more fragile against whatever happened.

It sorted out the coincidence theory.

I don't think it did. While it is clear that accessing address 0x2e on the SMBus causes system lockups or reboots (it has been tested repeatedly by different persons on different motherboards), the fact that your CPU died is still a single case, and the same experiments with a different CPU (fortunately) didn't kill it. So it is still possible that the death of your CPU at this moment was a coincidence (or put in another way, maybe your CPU would have died the day after without this, and the 0x2e probing just triggered it earlier.)

Quoted 10 lines

I agree with you that the
overclocked cpu was more fragile. I spotted a week ago that the cpu was not as robust as at the beginning.While inspecting the capabilities of the northbridge I ran stability testings for about ~30hrs with northbridge voltages at around 1.4V (1.3V is stock). After that the system was no longer stable at 2.8GHz with 1.3125V (1.3V stock). Going back to 2.7GHz fixed the stability issues. I ran this for at least a days without any problems till it froze. It was just a coincidence that i used lm-sensors and not typical windows monitoring tools.

Quoted 7 lines
Quoted 3 lines

Looks a lot like that older bug report I mentioned where probing address 0x2e rebooted the machine. Probably designed by the same person, using the same or similar chip.

Exactly in oposite to the user of the DFI Lanparty board with the nvidia chipset i get no hangups when i load the it87 module manual without parameters excluding 0x2e.

That's because I've since updated the it87 driver to no longer probe address 0x2e:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;hÅe3fbf22ccba0879b174fab7ec0e322b1266c2c
And then I even dropped the SMBus interface support from the it87 driver completely:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;hŽ9afcbbdef71aeeb510732f4f8d5ac3de863df0

If you were running an older kernel you'd experience the same problems the reported had when loading the it87 driver.

Quoted 7 lines
Quoted 6 lines

In general, people using a BIOS which was not meant for their motherboard should know that they are doing something wrong and should be ready to face the consequences. That being said, it would be easy enough to blacklist this other motherboard as well, presumably it has the same problems. Can you provide the dmidecode information for the DFI board / BIOS?

Quoted 5 lines

Other already tried to flash the dfi bios on the sapphire board and i also used it for weeks because the bios the board was shipped with had all type of issues.
So I switched to the latest stable DFI bios and attached a dmidecode dump here.

OK, thanks. Here's an updated patch which also blacklists the DFI variant.

Quoted 4 lines

I also tried i2cdump at 0x4e and 0x6e.
Same results as with the sapphire bios. Again the 0x6e dump stopped at 0x9e and outputs only XX till i reboot, a reload of the i2c-piix4 module does not help here.

I'm not surprised, I don't think it has anything to do with the BIOS, this is most probably a low-level hardware problem.

* * * * *

We had a report that running sensors-detect on a Sapphire AM2RD790 motherbord killed the CPU. While the exact cause is still unknown, I'd rather play it safe and prevent any access to the SMBus on that machine by not letting the i2c-piix4 driver attach to the SMBus host device on that machine.

---
 drivers/i2c/busses/i2c-piix4.c |   30 ++++++++++++++++++++++++++++--
 1 file changed, 28 insertions(+), 2 deletions(-)
drivers/i2c/busses/i2c-piix4.c +28 -2
@@ -108,7 +108,25 @@ static unsigned short piix4_smba;
 static struct pci_driver piix4_driver;
 static struct i2c_adapter piix4_adapter;
 
-static struct dmi_system_id __devinitdata piix4_dmi_table[] = {
+static struct dmi_system_id __devinitdata piix4_dmi_blacklist[] = {
+	{
+		.ident = "Sapphire AM2RD790",
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "SAPPHIRE Inc."),
+			DMI_MATCH(DMI_BOARD_NAME, "PC-AM2RD790"),
+		},
+		.ident = "DFI Lanparty UT 790FX",
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "DFI Inc."),
+			DMI_MATCH(DMI_BOARD_NAME, "LP UT 790FX"),
+		},
+	},
+	{ }
+};
+
+/* The IBM entry is in a separate table because we only check it
+   on Intel-based systems */
+static struct dmi_system_id __devinitdata piix4_dmi_ibm[] = {
 	{
 		.ident = "IBM",
 		.matches = { DMI_MATCH(DMI_SYS_VENDOR, "IBM"), },
@@ -123,8 +141,16 @@ static int __devinit piix4_setup(struct 
 
 	dev_info(&PIIX4_dev->dev, "Found %s device\n", pci_name(PIIX4_dev));
 
+	/* On some motherboards, it was reported that accessing the SMBus
+	   caused severe hardware problems */
+	if (dmi_check_system(piix4_dmi_blacklist)) {
+		dev_err(&PIIX4_dev->dev,
+			"Accessing the SMBus on this system is unsafe!\n");
+		return -EPERM;
+	}
+
 	/* Don't access SMBus on IBM systems which get corrupted eeproms */
-	if (dmi_check_system(piix4_dmi_table) &&
+	if (dmi_check_system(piix4_dmi_ibm) &&
 			PIIX4_dev->vendor = PCI_VENDOR_ID_INTEL) {
 		dev_err(&PIIX4_dev->dev, "IBM system detected; this module "
 			"may corrupt your serial eeprom! Refusing to load "
Signature · 6 lines
Jean Delvare

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
#20 lore raw
In reply to Achim Gottinger

Hi all,

ICS is now part of IDT. They sent to me the datasheet for my clockchip, quite fast. Please just make sure you read the chip labels correctly and I can try to write them once we know 100% that the chip names matches reality. I sometimes take a macro pictures of the chips instead of using magnifier.

Thanks,

Rudolf

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

author
#21 lore raw
In reply to Achim Gottinger

Am Sonntag, den 04.05.2008, 09:41 +0200 schrieb Jean Delvare:

Quoted 12 lines

Hi Achim,

Quoted 9 lines · Achim Gottinger

I took a picture of the board and numbered the chips.
http://www.abload.de/image.php?img=img_6532l9j.jpg

Chip 1-2 are the two NIC chips. Chip three is interesting. It was hard to read but i found that chip ICS9LPRS477BKL

I found that article later explaining that chip as an clock generator.
http://www.planet3dnow.de/vbulletin/showthread.php?t30028&garpg=6

Quoted 8 lines
Quoted 3 lines

Here are specs for a chip with an very similar number which is a clock generator chip.
http://www.idt.com/?genID=9LPRS478

There's also this one:
http://www.idt.com/?genID=9LPRS471

Maybe you misread the last 1 as a 7?

I misread nearly all characters in the first place ~0.5 mm text height is adveturous reading. Panet3dNow made a very clear picture of the chip I already posted a link to their webpage.

9LPRS471 and 9LPRS478 where clock generator chips for the 690G chipset. Googling for 9LPRS478 shows a link to the IDT page where you can download a datasheet. Fortunately I have such a board here.

i2cdetect -l shows the PIIX4 adapter
i2cdetect 0 shows there is someting at 0x50,0x51 and 0x69 none of those adddresses can be dumped. I Tried each one after a cold start, because as you expected this was required on the sapphire board to get the dump work again.

I also have an Gigabyte 780G board and an Asus M3A board (770 chipset) here.

The gigabyte has an 9LPRS477CKL chip and the M3A uses also the 9LPRS477BKL.

780G
i2cdetect -l shows the PIIX4 adapter
i2cdetect 0 shows there is someting at 0x50,0x51,0x52,0x53, 0x38,0x69

I attached the dumps of 0x38 and 0x69 to that mail.

Quoted 9 lines

Both chips have an SMBus interface so most certainly at least one of the addresses of i2cdetect corresponds to this chip. We'd need a datasheet but it doesn't seem to be available for download :(

Quoted 2 lines

Chip four is something like ICS 7714084.

Couldn't find anything about this one.

Same here but this chips is also very hard to read and the numbers might be similar looking characters like those i noted.

BTW: Both DFI Lanparty boards have a feature in common "CPU Overheat Protection function monitors CPU temperature during system boot-up"

Can be they use an separate chip for that, that is located below the chipset heatpipes.

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

author
#22 lore raw
In reply to Achim Gottinger

Am Sonntag, den 04.05.2008, 13:42 +0200 schrieb achim:

Quoted 41 lines

Am Sonntag, den 04.05.2008, 09:41 +0200 schrieb Jean Delvare:

Quoted 12 lines

Hi Achim,

Quoted 9 lines · Achim Gottinger

I took a picture of the board and numbered the chips.
http://www.abload.de/image.php?img=img_6532l9j.jpg

Chip 1-2 are the two NIC chips. Chip three is interesting. It was hard to read but i found that chip ICS9LPRS477BKL

I found that article later explaining that chip as an clock generator.
http://www.planet3dnow.de/vbulletin/showthread.php?t=330028&garpg=6

Quoted 8 lines
Quoted 3 lines

Here are specs for a chip with an very similar number which is a clock generator chip.
http://www.idt.com/?genID=9LPRS478

There's also this one:
http://www.idt.com/?genID=9LPRS471

Maybe you misread the last 1 as a 7?

I misread nearly all characters in the first place ~0.5 mm text height is adveturous reading. Panet3dNow made a very clear picture of the chip I already posted a link to their webpage.

9LPRS471 and 9LPRS478 where clock generator chips for the 690G chipset. Googling for 9LPRS478 shows a link to the IDT page where you can download a datasheet. Fortunately I have such a board here.

i2cdetect -l shows the PIIX4 adapter
i2cdetect 0 shows there is someting at 0x50,0x51 and 0x69 none of those adddresses can be dumped. I Tried each one after a cold start, because as you expected this was required on the sapphire board to get the dump work again.

I also have an Gigabyte 780G board and an Asus M3A board (770 chipset) here.

The gigabyte has an 9LPRS477CKL chip and the M3A uses also the 9LPRS477BKL.

Quoted 6 lines

780G
i2cdetect -l shows the PIIX4 adapter
i2cdetect 0 shows there is someting at 0x50,0x51,0x52,0x53, 0x38,0x69

I attached the dumps of 0x38 and 0x69 to that mail.

M3A-770
i2cdetect -l shows the PIIX4 adapter
i2cdetect 0 shows there is someting at 0x52,0x53, 0x38,0x69

I attached the dumps of 0x38 and 0x69 to that mail.

PS: Also added the dumps of the gbt board i forgott in the last mail. I'll try to modify a few frequencies and compare the dumps of 0x38 and 0x69 now.

Quoted 21 lines
Quoted 10 lines

Both chips have an SMBus interface so most certainly at least one of the addresses of i2cdetect corresponds to this chip. We'd need a datasheet but it doesn't seem to be available for download :(

Quoted 2 lines

Chip four is something like ICS 7714084.

Couldn't find anything about this one.

Same here but this chips is also very hard to read and the numbers might be similar looking characters like those i noted.

BTW: Both DFI Lanparty boards have a feature in common "CPU Overheat Protection function monitors CPU temperature during system boot-up"

Can be they use an separate chip for that, that is located below the chipset heatpipes.

Quoted 4 lines

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 01 00 00 00 00 50 ac 14 81 b4 08 10 7c 04 00 00    ?....P??????|?..
10: 01 00 00 00 00 50 ac 14 81 b4 08 10 7c 04 00 00    ?....P??????|?..
20: 01 00 00 00 00 50 ac 14 81 b4 08 10 7c 04 00 00    ?....P??????|?..
30: 01 00 00 00 00 50 ac 14 81 b4 08 10 7c 04 00 00    ?....P??????|?..
40: 01 00 00 00 00 50 ac 14 81 b4 08 10 7c 04 00 00    ?....P??????|?..
50: 01 00 00 00 00 50 ac 14 81 b4 08 10 7c 04 00 00    ?....P??????|?..
60: 01 00 00 00 00 50 ac 14 81 b4 08 10 7c 04 00 00    ?....P??????|?..
70: 01 00 00 00 00 50 ac 14 81 b4 08 10 7c 04 00 00    ?....P??????|?..
80: 01 00 00 00 00 50 ac 14 81 b4 08 10 7c 04 00 00    ?....P??????|?..
90: 01 00 00 00 00 50 ac 14 81 b4 08 10 7c 04 00 00    ?....P??????|?..
a0: 01 00 00 00 00 50 ac 14 81 b4 08 10 7c 04 00 00    ?....P??????|?..
b0: 01 00 00 00 00 50 ac 14 81 b4 08 10 7c 04 00 00    ?....P??????|?..
c0: 01 00 00 00 00 50 ac 14 81 b4 08 10 7c 04 00 00    ?....P??????|?..
d0: 01 00 00 00 00 50 ac 14 81 b4 08 10 7c 04 00 00    ?....P??????|?..
e0: 01 00 00 00 00 50 ac 14 81 b4 08 10 7c 04 00 00    ?....P??????|?..
f0: 01 00 00 00 00 50 ac 14 81 b4 08 10 7c 04 00 00    ?....P??????|?..
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef

00: XX 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 X
10: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 30: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20

40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
80: XX 7f ff ef ef 10 d0 75 31 08 cf 20 a5 00 00 00    X?.????u1?? ?...
90: 7a 3a f2 3b 00 8d 71 00 3c 06 0a 58 86 4d 71 06    z:?;.?q.<??X?Mq?
a0: 0a 0a 0a 71 71 71 71 71 71 00 3c ee 00 c0 00 fe    ???qqqqqq.<?.?.?
b0: 00 40 06 df 06 df 66 ff 00 45 66 a6 00 71 58 3a    .@????f..Ef?.qX:
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
10: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
20: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
30: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
40: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
50: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
60: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
70: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
80: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
90: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
a0: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
b0: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
c0: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
d0: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
e0: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
f0: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: XX 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21    X!!!!!!!!!!!!!!!
10: 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21    !!!!!!!!!!!!!!!!
20: 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21    !!!!!!!!!!!!!!!!
30: 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21    !!!!!!!!!!!!!!!!
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
80: XX ff ff ef ef 0f 0f 75 21 07 ef 2b e5 00 00 40    X..????u!??+?..@
90: bf 5e 00 3c 01 d3 a5 00 3c 86 d3 a5 86 8d 71 06    ?^.<???.<?????q?
a0: 0f 0f 0f 71 71 71 71 71 71 00 3c 74 00 c0 00 fe    ???qqqqqq.<t.?.?
b0: 00 40 06 df 06 df 66 fa 00 53 66 a6 00 a5 a5 5e    .@????f?.Sf?.??^
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

#23 lore raw
In reply to Achim Gottinger

Hi Achim,

Quoted 26 lines · achim

Am Sonntag, den 04.05.2008, 13:42 +0200 schrieb achim:

Quoted 25 lines

Am Sonntag, den 04.05.2008, 09:41 +0200 schrieb Jean Delvare:

Quoted 12 lines

Hi Achim,

Quoted 9 lines · Achim Gottinger

I took a picture of the board and numbered the chips.
http://www.abload.de/image.php?img=img_6532l9j.jpg

Chip 1-2 are the two NIC chips. Chip three is interesting. It was hard to read but i found that chip ICS9LPRS477BKL

I found that article later explaining that chip as an clock generator.
http://www.planet3dnow.de/vbulletin/showthread.php?t30028&garpg=6

Quoted 8 lines
Quoted 3 lines

Here are specs for a chip with an very similar number which is a clock generator chip.
http://www.idt.com/?genID=9LPRS478

There's also this one:
http://www.idt.com/?genID=9LPRS471

Maybe you misread the last 1 as a 7?

I misread nearly all characters in the first place ~0.5 mm text height is adveturous reading. Panet3dNow made a very clear picture of the chip I already posted a link to their webpage.

Ah, sorry, I missed that. OK, the picture really says 9LPRS477BKL. Odd that there is no reference to this on the IDT website. Rudolf, can you please try to get information about this chip? If you can also get information about the '471 and '478 models, that would be great too.

Quoted 3 lines
Quoted 3 lines

9LPRS471 and 9LPRS478 where clock generator chips for the 690G chipset. Googling for 9LPRS478 shows a link to the IDT page where you can download a datasheet.

I already tried this, unfortunately the link is apparently to a datasheet for a different chip (ICS951464). I can tell it's not the same chip because the 9LPRS478 is in a VFQFPN 72 package (square, with pins on 4 sides) while the 951464 is rectangular with pins on 2 sides.

Quoted 4 lines
Quoted 4 lines

Fortunately I have such a board here.

i2cdetect -l shows the PIIX4 adapter
i2cdetect 0 shows there is someting at 0x50,0x51 and 0x69

0x69 is the address of the ICS951464 according to the datasheet.

Quoted 3 lines
Quoted 3 lines

none of those adddresses can be dumped. I Tried each one after a cold start, because as you expected this was required on the sapphire board to get the dump work again.

Hmmm, that's strange. 0x50 and 0x51 are your memory module SPD EEPROMs, they should be dumpable. For 0x69 you should use the "s" mode of i2cdump.

Quoted 17 lines
Quoted 7 lines

I also have an Gigabyte 780G board and an Asus M3A board (770 chipset) here.

The gigabyte has an 9LPRS477CKL chip and the M3A uses also the 9LPRS477BKL.

Quoted 6 lines

780G
i2cdetect -l shows the PIIX4 adapter
i2cdetect 0 shows there is someting at 0x50,0x51,0x52,0x53, 0x38,0x69

I attached the dumps of 0x38 and 0x69 to that mail.

M3A-770
i2cdetect -l shows the PIIX4 adapter
i2cdetect 0 shows there is someting at 0x52,0x53, 0x38,0x69

Quoted 5 lines

I attached the dumps of 0x38 and 0x69 to that mail.

PS: Also added the dumps of the gbt board i forgott in the last mail. I'll try to modify a few frequencies and compare the dumps of 0x38 and 0x69 now.

No idea what is the chip at 0x38. At 0x69 it's usually clock chips.

Note that sensors-detect (at least recent versions thereof) doesn't probe address 0x38 nor 0x69, as there are no known hardware monitoring chips using these addresses.

Signature · 6 lines
Jean Delvare

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
author
#24 lore raw
In reply to Achim Gottinger

Am Sonntag, den 04.05.2008, 14:39 +0200 schrieb Jean Delvare:

Quoted 44 lines

Hi Achim,

Quoted 26 lines · achim

Am Sonntag, den 04.05.2008, 13:42 +0200 schrieb achim:

Quoted 25 lines

Am Sonntag, den 04.05.2008, 09:41 +0200 schrieb Jean Delvare:

Quoted 12 lines

Hi Achim,

Quoted 9 lines · Achim Gottinger

I took a picture of the board and numbered the chips.
http://www.abload.de/image.php?img=img_6532l9j.jpg

Chip 1-2 are the two NIC chips. Chip three is interesting. It was hard to read but i found that chip ICS9LPRS477BKL

I found that article later explaining that chip as an clock generator.
http://www.planet3dnow.de/vbulletin/showthread.php?t30028&garpg=6

Quoted 8 lines
Quoted 3 lines

Here are specs for a chip with an very similar number which is a clock generator chip.
http://www.idt.com/?genID=9LPRS478

There's also this one:
http://www.idt.com/?genID=9LPRS471

Maybe you misread the last 1 as a 7?

I misread nearly all characters in the first place ~0.5 mm text height is adveturous reading. Panet3dNow made a very clear picture of the chip I already posted a link to their webpage.

Ah, sorry, I missed that. OK, the picture really says 9LPRS477BKL. Odd that there is no reference to this on the IDT website. Rudolf, can you please try to get information about this chip? If you can also get information about the '471 and '478 models, that would be great too.

Quoted 3 lines
Quoted 3 lines

9LPRS471 and 9LPRS478 where clock generator chips for the 690G chipset. Googling for 9LPRS478 shows a link to the IDT page where you can download a datasheet.

I already tried this, unfortunately the link is apparently to a datasheet for a different chip (ICS951464). I can tell it's not the same chip because the 9LPRS478 is in a VFQFPN 72 package (square, with pins on 4 sides) while the 951464 is rectangular with pins on 2 sides.

Quoted 6 lines
Quoted 4 lines
Quoted 4 lines

Fortunately I have such a board here.

i2cdetect -l shows the PIIX4 adapter
i2cdetect 0 shows there is someting at 0x50,0x51 and 0x69

0x69 is the address of the ICS951464 according to the datasheet.

Yepp, I tried different ref HT and PCIe clocks and that result in a different output of the 0x69 dump.

The odd thing is the Sapphire board uses the same clock chip as the M3A but does not show that chip at 0x69.

Quoted 9 lines
Quoted 4 lines
Quoted 4 lines

none of those adddresses can be dumped. I Tried each one after a cold start, because as you expected this was required on the sapphire board to get the dump work again.

Hmmm, that's strange. 0x50 and 0x51 are your memory module SPD EEPROMs, they should be dumpable. For 0x69 you should use the "s" mode of i2cdump.

I must use nolapci and irqpoll to boot the 2.6.24 kernel on that machine, does this have an impact?

Quoted 5 lines
Quoted 4 lines
Quoted 4 lines

I also have an Gigabyte 780G board and an Asus M3A board (770 chipset) here.


No idea what is the chip at 0x38. At 0x69 it's usually clock chips.

Maybe it is the voltage regulator chip, on the M3A it's this one

ISL6559
http://www.st.com/stonline/products/literature/ds/13605.pdf

on the GBt board it's a ISL6323
http://www.intersil.com/data/fn/fn9278.pdf

The sapphire board has digital PWM and no voltage regulator chip.

The DFI Lanparty NF4 has an voltage regulator chip at the right bottom
http://www.techpowerup.com/reviews/DFI/LPNF4Expert/images/board.jpg

http://www.techpowerup.com/reviews/DFI/LPNF4Expert/images/cpuarea.jpg
ISL6559CB

All those voltage regulator chips seem to have no smbus interface so the chip at 0x2e and 0x4e must be something different.

At 0x6e i'd expect the clock generator. I'll switch back to the sapphire board now and will do some ref HT modifications there. Is there a simple way to skip the reading at 0x9e?

I found the part number of chip number four. :)
It's an ICS9DB403DGLF

http://www.idt.com/?genID�B403

I just skimmed over the specs, that chip is related to the pcie and has an smbus interface.

How did you find out the address of the 690G clock chips by looking at the specs?

Quoted 5 lines

Note that sensors-detect (at least recent versions thereof) doesn't probe address 0x38 nor 0x69, as there are no known hardware monitoring chips using these addresses.

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

author
#25 lore raw
In reply to Achim Gottinger
Quoted 2 lines

The odd thing is the Sapphire board uses the same clock chip as the M3A but does not show that chip at 0x69.

Now with the 9600BE in the sapphire board there are additional chips

X2 5000BE
---------------------------------------------------
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 2e -- 30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 4e -- 50: -- -- 52 53 -- -- -- 57 -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 6e -- 70: 70 -- -- -- -- -- -- --
---------------------------------------------------

9600BE ---------------------------------------------------
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 2e -- 30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- 47 -- -- -- -- 4c -- 4e -- 50: -- -- 52 53 -- -- -- 57 -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- 6e -- 70: 70 -- -- -- -- -- -- -- ---------------------------------------------------

Now the clock chips shows up at 0x69 maybe a second run with the X2 would also have shown it.

I spotted one thing. The output of 0x38 is identical on the M3A and the Sapphire board and slightly different on the GBT board.
M3A and Sapphire use the same clock chip 9LPRS477BKL the GBT an 9LPRS477CKL. Seems this 0x38 address also point to the cloch generator.

I tried all types of bios modifications but none showed up at the dumps of 0x4e and 0x6e.

Trying to dump 0x47 results in XX till i reboot.

For the record I attached the dumps of 0x38 0x57 0x4c 0x69 0x6e and 0x70

If I run sensors-detect and pass 0x2e,0x6e,0x47 as excludes, will it pass?

With the current patch applied the scanning will be completely skipped, so i can't test the patch atm.

Quoted 61 lines
Quoted 10 lines
Quoted 5 lines
Quoted 5 lines

none of those adddresses can be dumped. I Tried each one after a cold start, because as you expected this was required on the sapphire board to get the dump work again.

Hmmm, that's strange. 0x50 and 0x51 are your memory module SPD EEPROMs, they should be dumpable. For 0x69 you should use the "s" mode of i2cdump.

I must use nolapci and irqpoll to boot the 2.6.24 kernel on that machine, does this have an impact?

Quoted 5 lines
Quoted 4 lines
Quoted 4 lines

I also have an Gigabyte 780G board and an Asus M3A board (770 chipset) here.


No idea what is the chip at 0x38. At 0x69 it's usually clock chips.

Maybe it is the voltage regulator chip, on the M3A it's this one

ISL6559
http://www.st.com/stonline/products/literature/ds/13605.pdf

on the GBt board it's a ISL6323
http://www.intersil.com/data/fn/fn9278.pdf

The sapphire board has digital PWM and no voltage regulator chip.

The DFI Lanparty NF4 has an voltage regulator chip at the right bottom
http://www.techpowerup.com/reviews/DFI/LPNF4Expert/images/board.jpg

http://www.techpowerup.com/reviews/DFI/LPNF4Expert/images/cpuarea.jpg
ISL6559CB

All those voltage regulator chips seem to have no smbus interface so the chip at 0x2e and 0x4e must be something different.

At 0x6e i'd expect the clock generator. I'll switch back to the sapphire board now and will do some ref HT modifications there. Is there a simple way to skip the reading at 0x9e?

I found the part number of chip number four. :)
It's an ICS9DB403DGLF

http://www.idt.com/?genID=9DB403

I just skimmed over the specs, that chip is related to the pcie and has an smbus interface.

How did you find out the address of the 690G clock chips by looking at the specs?

Quoted 5 lines

Note that sensors-detect (at least recent versions thereof) doesn't probe address 0x38 nor 0x69, as there are no known hardware monitoring chips using these addresses.

Quoted 4 lines

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 14 00 00 08 00 00 46 00 00 00 00 00 00 00 00    .?..?..F........
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
30: 45 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    E...............
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 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: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 02 00 05 05 3f 00 00 00 00 00 00 00 00 00 00 00    ?.???...........
10: 00 00 ff 0f 00 00 00 00 00 00 00 00 00 00 00 00    ...?............
20: 00 00 00 00 00 00 00 00 83 12 12 28 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 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: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
10: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
20: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
30: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
40: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
50: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
60: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
70: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
80: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
90: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
a0: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
b0: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
c0: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
d0: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
e0: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
f0: 01 00 00 00 00 40 2c 14 00 b4 08 00 7c 04 00 00    ?....@,?.??.|?..
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 68 6e 6d ff 00 00 ff ff 00 00 00 ff 00 00 ff ff    hnm.............
10: 00 00 00 ff 00 00 ff ff 00 00 00 ff 00 00 ff ff    ................
20: 30 32 30 ff 00 00 ff ff 00 00 00 ff 00 00 ff ff    020.............
30: 00 00 00 ff 00 00 ff ff 00 00 00 ff 45 34 ff ff    ............E4..
40: 34 00 00 ff 00 00 ff ff 00 00 00 ff 00 00 ff ff    4...............
50: 00 00 00 ff 00 00 ff ff 00 00 45 ff 30 33 ff ff    ..........E.03..
60: 00 00 00 ff 00 00 ff ff 00 00 00 ff 00 00 ff ff    ................
70: 00 00 00 ff 00 00 ff ff 00 00 00 ff 00 00 ff ff    ................
80: ff ff 5a ff 5a ff ff ff fc f2 80 ff 2f ff ff ff    ..Z.Z...???./...
90: 00 00 00 ff 00 ff ff ff ff ff ff ff 80 0f ff ff    ............??..
a0: f0 d7 11 ff fe fd ff ff ed e1 ff ff ff 00 ff ff    ???.??..??......
b0: f8 ff 21 ff ff ff ff ff ff ff ff ff ff 2a ff ff    ?.!..........*..
c0: c4 ff ff ff f0 c9 ff ff ef ff ff ff c0 80 ff ff    ?...??..?...??..
d0: ff ff ff ff ca de ff ff 81 01 01 ff 81 4b ff ff    ....??..???.?K..
e0: 80 80 80 ff 80 aa ff ff ff ff ea ff fe 95 ff ff    ???.??....?.??..
f0: 4a fe 00 ff f5 ff ff ff 00 00 00 ff 5a ff ff ff    J?..?.......Z...
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: XX 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21    X!!!!!!!!!!!!!!!
10: 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21    !!!!!!!!!!!!!!!!
20: 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21    !!!!!!!!!!!!!!!!
30: 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21 21    !!!!!!!!!!!!!!!!
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
80: XX 7f ff ef ef 0f 0f 75 21 07 ef 20 a5 00 00 40    X?.????u!?? ?..@
90: 32 4b 00 3c 01 8d 71 00 3c 06 8d 71 06 8d 71 06    2K.<??q.<??q??q?
a0: 0f 0f 0f 71 71 71 71 71 71 00 3c 74 00 c0 00 fe    ???qqqqqq.<t.?.?
b0: 00 40 06 df 06 df 66 fa 00 53 66 a6 00 71 71 4b    .@????f?.Sf?.qqK
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 30 00 08 04 1d 13 00 81 00 00 00 00 00 d8 06 00    0.????.?.....??.
10: 00 13 05 00 00 00 00 00 cd 01 0b 00 98 55 00 24    .??.....???.?U.$
20: 42 81 11 11 00 00 00 00 00 00 00 00 5c 98 00 ff    B???........\?..
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
40: 30 00 08 04 1d 13 00 81 00 00 00 00 00 d8 06 00    0.????.?.....??.
50: 00 13 05 00 00 00 00 00 cd 01 0b 00 98 55 00 00    .??.....???.?U..
60: 42 80 11 11 00 00 00 00 00 00 00 00 5c 98 00 ff    B???........\?..
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
80: 30 00 08 04 1d 13 00 81 00 00 00 00 00 d8 06 00    0.????.?.....??.
90: 00 13 05 00 00 00 00 00 cd 01 0b 00 98 55 00 00    .??.....???.?U..
a0: 42 80 11 11 00 00 00 00 00 00 00 00 5c 98 00 ff    B???........\?..
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
c0: 30 00 08 04 1d 13 00 81 00 00 00 00 00 d8 06 00    0.????.?.....??.
d0: 00 13 05 00 00 00 00 00 cd 01 0b 00 98 55 81 00    .??.....???.?U?.
e0: 42 82 11 11 00 00 00 00 00 00 00 00 5c 98 00 ff    B???........\?..
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

#26 lore raw
In reply to Achim Gottinger
Quoted 2 lines · achim

The odd thing is the Sapphire board uses the same clock chip as the M3A but does not show that chip at 0x69.

Note that there's a chip at 0x70 on the Sapphire motherboard, I've already seen mux chips at this address. So maybe the clock chip at 0x69 is there but on a branch of the mux which isn't currently active.

As a side note, I think it would have been really great if whatever chip at 0x2e was behind a gate or mux so that it can't be accessed by default. This would have avoided all the trouble.

Quoted 2 lines

I must use nolapci and irqpoll to boot the 2.6.24 kernel on that machine, does this have an impact?

Shouldn't, as the i2c-piix4 driver doesn't use interrupts.

Quoted 4 lines

Maybe it is the voltage regulator chip, on the M3A it's this one

ISL6559
http://www.st.com/stonline/products/literature/ds/13605.pdf

This one is using Send Byte, which is a write transaction that starts the same as a Read Byte transaction. sensors-detect would effectively write to this chips while probing it. To make things worse, it apparently acks all addresses from 0x60 to 0x6f. The good news is that senors-detect no longer probes these addresses, so we're safe.

I can only imagine that whatever chip at 0x2e is causing trouble, it also uses Send Byte transactions. It will see basically random writes from the sensors-detect script, resulting in random VID codes and in turn random Vcore to be applied to the CPU. No good.

Unfortunately it can't be helped. Such chips could live at virtually any address and be found on any motherboard, so the only safe solution would be to plain stop probing for chips on the SMBus.

Quoted 2 lines

on the GBt board it's a ISL6323
http://www.intersil.com/data/fn/fn9278.pdf

Couldn't find how this one is accessed.

Quoted 8 lines

The sapphire board has digital PWM and no voltage regulator chip.

The DFI Lanparty NF4 has an voltage regulator chip at the right bottom
http://www.techpowerup.com/reviews/DFI/LPNF4Expert/images/board.jpg

http://www.techpowerup.com/reviews/DFI/LPNF4Expert/images/cpuarea.jpg
ISL6559CB

Quoted 6 lines

All those voltage regulator chips seem to have no smbus interface so the chip at 0x2e and 0x4e must be something different.

At 0x6e i'd expect the clock generator. I'll switch back to the sapphire board now and will do some ref HT modifications there. Is there a simple way to skip the reading at 0x9e?

Starting with i2c-tools version 3.0.1, you can provide a range or registers to read from, with -r. If you choose -r 0-0x9d, I guess you will avoid the lockup.

Quoted 7 lines

I found the part number of chip number four. :)
It's an ICS9DB403DGLF

http://www.idt.com/?genID�B403

I just skimmed over the specs, that chip is related to the pcie and has an smbus interface.

And lives at address 0x6e.

Quoted 2 lines

How did you find out the address of the 690G clock chips by looking at the specs?

Search for "slave address". The datasheet says it sends byte D2 to write to slave and D3 to read from it. The address byte is the 7-bit slave address + 1 read/write bit (0 for write, 1 for read). So you get the slave address by shifting address byte by 1 to the right (i.e. dividing it by 2): 0xD2/2 = 0x69.

Signature · 6 lines
Jean Delvare

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
#27 lore raw
In reply to Achim Gottinger
Quoted 28 lines · achim

Now with the 9600BE in the sapphire board there are additional chips

X2 5000BE
---------------------------------------------------
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 2e -- 30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 4e -- 50: -- -- 52 53 -- -- -- 57 -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 6e -- 70: 70 -- -- -- -- -- -- --
---------------------------------------------------

9600BE ---------------------------------------------------
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 2e -- 30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- 47 -- -- -- -- 4c -- 4e -- 50: -- -- 52 53 -- -- -- 57 -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- 6e -- 70: 70 -- -- -- -- -- -- -- ---------------------------------------------------

Quoted 2 lines

Now the clock chips shows up at 0x69 maybe a second run with the X2 would also have shown it.

Strange... This could be related to the chip at 0x70 if it's an I2C mux as I suspect. Another possibility would be that the extra addresses are in the CPU itself, but at least for 0x69 we know it's not the case.

Quoted 10 lines

I spotted one thing. The output of 0x38 is identical on the M3A and the Sapphire board and slightly different on the GBT board.
M3A and Sapphire use the same clock chip 9LPRS477BKL the GBT an 9LPRS477CKL. Seems this 0x38 address also point to the cloch generator.

I tried all types of bios modifications but none showed up at the dumps of 0x4e and 0x6e.

Trying to dump 0x47 results in XX till i reboot.

Never seen a chip at this address. sensors-detect does probe it, because the Maxim MAX6633 can use this address in theory. However if it is dangerous to probe this address, I think I'll just remove the probe. We're probing 0x40-0x47 only for the MAX6633 and it's a rather rare chip - not sure if we already saw a single user with it, so the risk is just not worth the benefit.

Quoted 2 lines

For the record I attached the dumps of 0x38 0x57 0x4c 0x69 0x6e and 0x70

Doesn't look like anything I know. The chip at 0x70 doesn't look like a mux after all.

Quoted 2 lines

If I run sensors-detect and pass 0x2e,0x6e,0x47 as excludes, will it pass?

Yes, it should pass.

Quoted 2 lines

With the current patch applied the scanning will be completely skipped, so i can't test the patch atm.

Of course. The second patch I sent was broken anyway, I've resent it to the i2c list already but didn't Cc you, sorry. I'll send an updated patch to you now.

Signature · 6 lines
Jean Delvare

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
#28 lore raw
In reply to Achim Gottinger
Quoted 8 lines · Jean Delvare
Quoted 3 lines · achim

The odd thing is the Sapphire board uses the same clock chip as the M3A but does not show that chip at 0x69.

Note that there's a chip at 0x70 on the Sapphire motherboard, I've already seen mux chips at this address.

You lost me here, :)

Quoted 19 lines

So maybe the clock chip at 0x69
is there but on a branch of the mux which isn't currently active.

As a side note, I think it would have been really great if whatever chip at 0x2e was behind a gate or mux so that it can't be accessed by default. This would have avoided all the trouble.

Quoted 5 lines

Maybe it is the voltage regulator chip, on the M3A it's this one

ISL6559
http://www.st.com/stonline/products/literature/ds/13605.pdf

This one is using Send Byte, which is a write transaction that starts the same as a Read Byte transaction. sensors-detect would effectively write to this chips while probing it. To make things worse, it apparently acks all addresses from 0x60 to 0x6f. The good news is that senors-detect no longer probes these addresses, so we're safe.

Quoted 10 lines

I can only imagine that whatever chip at 0x2e is causing trouble, it also uses Send Byte transactions. It will see basically random writes from the sensors-detect script, resulting in random VID codes and in turn random Vcore to be applied to the CPU. No good.

Unfortunately it can't be helped. Such chips could live at virtually any address and be found on any motherboard, so the only safe solution would be to plain stop probing for chips on the SMBus.

Thank you for the detailed explanation.

The M3A seems to have only the clock generator in that range at 0x69. 0x6e has turned out to be related to pcie.
0x2e and 0x4e are common between the DFI Lanparty NF4 and the Lanparty UT 790X but the first one uses
an analouge pwm and the second one an digital one, which does not need an voltage gereator chip i guess.

I found one additional thing at 0x4e. When I put in the phenom 0x02 and 0x04 readings both change from 0x00 to 0x05. The rest stays the same. The output of 0x38 and 0x6e did not change after switching the cpu's.

The M2A-VM (690G chipset) only shows an chip at 0x69 whom i was able to get a dump from. It's also a clock generator chip and the output changes if i change the ref HT from 200MHz to 201MHz. In opposite to the clock generators on the 0x7xx chipsets this board has no chip at 0x38. So I'm unsure now if the chip at 0x38 can also be associated to the clock generator.

Quoted 9 lines
Quoted 3 lines

on the GBt board it's a ISL6323
http://www.intersil.com/data/fn/fn9278.pdf

Starting with i2c-tools version 3.0.1, you can provide a range or registers to read from, with -r. If you choose -r 0-0x9d, I guess you will avoid the lockup.

Thanks, i'll reinspect that register.

Quoted 4 lines
Quoted 4 lines

I found the part number of chip number four. :)
It's an ICS9DB403DGLF

Quoted 8 lines
Quoted 5 lines

http://www.idt.com/?genID�B403

I just skimmed over the specs, that chip is related to the pcie and has an smbus interface.

And lives at address 0x6e.

Great one unknown chip sorted out. :)

Quoted 11 lines
Quoted 4 lines

How did you find out the address of the 690G clock chips by looking at the specs?

Search for "slave address". The datasheet says it sends byte D2 to write to slave and D3 to read from it. The address byte is the 7-bit slave address + 1 read/write bit (0 for write, 1 for read). So you get the slave address by shifting address byte by 1 to the right (i.e. dividing it by 2): 0xD2/2 = 0x69.

So in theory it might be possible to change for example the ref HT speed by writing to 0x68? Is there a project alive utilising those clock generator chips under linux?
For monitoring purpose an module which reads the ref HT and PCIe bus speeds might be interesting. I think about trying to write one. :)

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

#29 lore raw
In reply to Achim Gottinger
Quoted 30 lines · Jean Delvare
Quoted 28 lines · achim

Now with the 9600BE in the sapphire board there are additional chips

X2 5000BE
---------------------------------------------------
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 2e -- 30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 4e -- 50: -- -- 52 53 -- -- -- 57 -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 6e -- 70: 70 -- -- -- -- -- -- --
---------------------------------------------------

9600BE ---------------------------------------------------
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 2e -- 30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- 47 -- -- -- -- 4c -- 4e -- 50: -- -- 52 53 -- -- -- 57 -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- 6e -- 70: 70 -- -- -- -- -- -- -- ---------------------------------------------------

Quoted 8 lines
Quoted 3 lines

Now the clock chips shows up at 0x69 maybe a second run with the X2 would also have shown it.

Strange... This could be related to the chip at 0x70 if it's an I2C mux as I suspect. Another possibility would be that the extra addresses are in the CPU itself, but at least for 0x69 we know it's not the case.

I searched the "Bios and Kernel Developer Guide" for smbus and found those results

http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116.PDF

------------------------------------------------------------------------------------------------
• SMBus. System management bus. Refers to the protocol on which the serial VID interface (SVI) commands
and SBI are based. See section 2.4.1 [Processor Power Planes And Voltage Control] on page 28, 2.13.3
[Sideband Interface (SBI)] on page 123, and section 1.2 [Reference Documents] on page 13.
------------------------------------------------------------------------------------------------
2.4.1 Processor Power Planes And Voltage Control

The processor includes the following power planes:
• VDDIO: used for the DRAM and miscellaneous pins on DDR products only. Voltage level is nominally 1.8V
or 1.9V in support of DDR2; 1.5V in support of DDR3. This plane is powered during S3 (suspend to RAM).
• VTT: used for the DDR DRAM interface. Voltage level is specified to be half of the VDDIO level. This
plane is powered during S3 (suspend to RAM). See section 2.4.4 [ACPI Suspend to RAM State (S3)] on
page 52.
• VLDT: used for each of the links. Voltage level is nominally 1.2V.
• VDDA: filtered PLL supply. Voltage level is nominally 2.5V.
• VDD or VDD[1:0]: main supply for core logic. “VDD” refers generically to the core voltage plane(s). Voltage
level is specified by the VID interface.
• VDDNB: main supply for NB logic. Voltage level specified by the VID interface.
The voltage level of VDD and VDDNB may be altered in various states to control power consumption. All the
other supplies are fixed. Refer to the EDS for power plane sequencing requirements.
The processor includes two interfaces, intended to control external voltage regulators, called the parallel VID
(voltage level identifier) interface (PVI) and the serial VID interface (SVI). The PVI is a simple 6-bit VID code
provided on 6 pins. The SVI encodes voltage regulator control commands, including the VID code, using
SMBus protocol over two pins, SVD and SVC, to generate write commands to external voltage regulators. The
processor is the master and the voltage regulator(s) are the slave(s). Both pins are outputs of the master; SVD is
driven by the slave as well. SVC is a clock that strobes the data pin, SVD, on the rising edge. Refer to the AMD
------------------------------------------------------------------------------------------------
2.13.3 Sideband Interface (SBI)

The sideband interface (SBI) is an SMBus v2.0 compatible 2-wire processor slave interface. SBI is also
referred as the Advanced Platform Management Link. All I2C v2.1 speeds are supported.
SBI is used to communicate withthe Temperature Sensor Interface (SB-TSI) (see the SBI Temperature Sensor
Interface (SB-TSI) Specification, #40821).
------------------------------------------------------------------------------------------------
Information about the SBI SMBus register address can be read from the pci register F3x1E8. lspci does not output values beyond 0xFF. However baredit
under windows does. I could not find the SB-TSI document at the amd website. Will look at this thing again tomorrow.

Quoted 7 lines
Quoted 4 lines

If I run sensors-detect and pass 0x2e,0x6e,0x47 as excludes, will it pass?

Yes, it should pass.

Good, i'll try that.

I also skimmed over the SB600 doc.
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/42119_sb600_ds_nda_3.02.pdf
Maybe the chip at 0x38 is the south bridge. On the M3A and the Sapphire this is SB600 and on the GBT780G it's SB700. The M2A-VM might simply not use the smbus.

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

#30 lore raw
In reply to Achim Gottinger
Quoted 51 lines · Achim Gottinger

I searched the "Bios and Kernel Developer Guide" for smbus and found those results

http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116.PDF

------------------------------------------------------------------------------------------------
• SMBus. System management bus. Refers to the protocol on which the serial VID interface (SVI) commands
and SBI are based. See section 2.4.1 [Processor Power Planes And Voltage Control] on page 28, 2.13.3
[Sideband Interface (SBI)] on page 123, and section 1.2 [Reference Documents] on page 13.
------------------------------------------------------------------------------------------------
2.4.1 Processor Power Planes And Voltage Control

The processor includes the following power planes:
• VDDIO: used for the DRAM and miscellaneous pins on DDR products only. Voltage level is nominally 1.8V
or 1.9V in support of DDR2; 1.5V in support of DDR3. This plane is powered during S3 (suspend to RAM).
• VTT: used for the DDR DRAM interface. Voltage level is specified to be half of the VDDIO level. This
plane is powered during S3 (suspend to RAM). See section 2.4.4 [ACPI Suspend to RAM State (S3)] on
page 52.
• VLDT: used for each of the links. Voltage level is nominally 1.2V.
• VDDA: filtered PLL supply. Voltage level is nominally 2.5V.
• VDD or VDD[1:0]: main supply for core logic. “VDD” refers generically to the core voltage plane(s). Voltage
level is specified by the VID interface.
• VDDNB: main supply for NB logic. Voltage level specified by the VID interface.
The voltage level of VDD and VDDNB may be altered in various states to control power consumption. All the
other supplies are fixed. Refer to the EDS for power plane sequencing requirements.
The processor includes two interfaces, intended to control external voltage regulators, called the parallel VID
(voltage level identifier) interface (PVI) and the serial VID interface (SVI). The PVI is a simple 6-bit VID code
provided on 6 pins. The SVI encodes voltage regulator control commands, including the VID code, using
SMBus protocol over two pins, SVD and SVC, to generate write commands to external voltage regulators. The
processor is the master and the voltage regulator(s) are the slave(s). Both pins are outputs of the master; SVD is
driven by the slave as well. SVC is a clock that strobes the data pin, SVD, on the rising edge. Refer to the AMD
------------------------------------------------------------------------------------------------
2.13.3 Sideband Interface (SBI)

Quoted 8 lines

The sideband interface (SBI) is an SMBus v2.0 compatible 2-wire processor slave interface. SBI is also
referred as the Advanced Platform Management Link. All I2C v2.1 speeds are supported.
SBI is used to communicate withthe Temperature Sensor Interface (SB-TSI) (see the SBI Temperature Sensor
Interface (SB-TSI) Specification, #40821).
------------------------------------------------------------------------------------------------

There's probably a lot to read and do there, too bad I don't have the time :(

Quoted 2 lines

Information about the SBI SMBus register address can be read from the pci register F3x1E8. lspci does not output values beyond 0xFF.

It does :) You only have to swap the bytes yourself due to x86 being little-endian. Better use setpci with no value, you can tell it the width of the register (.w for 16-bit, .l for 32-bit.)

Signature · 6 lines
Jean Delvare

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
author
#31 lore raw
In reply to Achim Gottinger

Am Sonntag, den 04.05.2008, 20:16 +0200 schrieb Jean Delvare:

Quoted 9 lines · Achim Gottinger
Quoted 5 lines

I searched the "Bios and Kernel Developer Guide" for smbus and found those results

http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116.PDF

There's probably a lot to read and do there, too bad I don't have the time :(

He He, the BKDG is tough to read. I tried to figure out the SMbus adresses.

http://www.abload.de/image.php?img=baredit-sidebandeis.jpg

This is the register where the adress should be in bits 4:6 whom are all zero. However bit 3 is set and that should mean that the sideband interface is used.

http://www.abload.de/image.php?img=sidebandumy.jpg

I plan to ask amd for clarification and for that SBI document they rerefer to. I also plan to RMA my cpu btw.

Quoted 8 lines
Quoted 3 lines

Information about the SBI SMBus register address can be read from the pci register F3x1E8. lspci does not output values beyond 0xFF.

It does :) You only have to swap the bytes yourself due to x86 being little-endian. Better use setpci with no value, you can tell it the width of the register (.w for 16-bit, .l for 32-bit.)

Thank you for the tip. But under linux only the address space from 0x00-0xFF is accesible thru /proc/bus/pci...
I tried to access 0x1E4 that way

setpci -s 0:18.3 0x1E4.l

and only got 0xFFFFFFFF back. Same happens if i try to read from /proc/bus/pci/00/18.3 direct (with a small python script).

I tried to read out 0x6e with the -r option. It is possible to read the following areas without making the smbus controler nonfunctional. 0x00-0x7F,
0x80-0x9d,0xa0-0xbd,0xc0-0xdd,0xe0-0xfd

ALso i tried to run sensors-detect with excluding 0x2e,0x6e and 0x47. It passed but afterwards I had to restart to get rid of the XX'es in the i2cdump.

debian-9850:/home/achim# sensors-detect 
# sensors-detect revision 5108 (2008-01-22 13:22:47 +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):
Probing for PCI bus adapters...
Use driver `i2c-piix4' for device 0000:00:14.0: ATI Technologies Inc SB600 SMBus

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

To continue, we need module i2c-dev' to be loaded. Do you want to load i2c-dev' now? (YES/no):
Module loaded successfully.

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 PIIX4 adapter at 0b00 (i2c-0)
Do you want to scan it? (YES/no/selectively): selectively Please enter one or more addresses not to scan. Separate them with comma's. You can specify a range by using dashes. Addresses may be decimal (like 54) or hexadecimal (like 0x33).
Addresses: 0x2e,0x6e,0x47
Client found at address 0x4c

Probing for `National Semiconductor LM75'...                No
Probing for `Dallas Semiconductor DS75'...                  No
Probing for `Analog Devices ADT7466'...                     No
Probing for `Andigilog aSC7511'...                          No
Probing for `Dallas Semiconductor DS1621'...                No
Probing for `Analog Devices ADM1021'...                     No
Probing for `Analog Devices ADM1021A/ADM1023'...            No
Probing for `Maxim MAX1617'...                              No
Probing for `Maxim MAX1617A'...                             No
Probing for `Maxim MAX1668'...                              No
Probing for `Maxim MAX1805'...                              No
Probing for `Maxim MAX1989'...                              No
Probing for `Maxim MAX6655/MAX6656'...                      No
Probing for `TI THMC10'...                                  No
Probing for `National Semiconductor LM84'...                No
Probing for `Genesys Logic GL523SM'...                      No
Probing for `Onsemi MC1066'...                              No
Probing for `Maxim MAX1619'...                              No
Probing for `National Semiconductor LM82/LM83'...           No
Probing for `National Semiconductor LM90'...                No
Probing for `National Semiconductor LM89/LM99'...           No
Probing for `National Semiconductor LM86'...                No
Probing for `Analog Devices ADM1032'...                     No
Probing for `Maxim MAX6657/MAX6658/MAX6659'...              No
Probing for `Maxim MAX6648/MAX6692'...                      No
Probing for `Maxim MAX6680/MAX6681'...                      No
Probing for `Winbond W83L771W/G'...                         No
Probing for `Texas Instruments TMP401'...                   No
Probing for `National Semiconductor LM63'...                No
Probing for `Fintek F75363SG'...                            No
Probing for `Maxim MAX6633/MAX6634/MAX6635'...              No
Probing for `Analog Devices ADT7461'...                     No
Probing for `Fintek F75383S/M'...                           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):

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):
Probing for Super-I/O at 0x2e/0x2f

Trying family `National Semiconductor'...                   No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Fintek'...                       No
Trying family `ITE'...                                      Yes
Found `ITE IT8716F Super IO Sensors'                        Success!
    (address 0x228, driver `it87')
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):
AMD K8 thermal sensors... No
AMD K10 thermal sensors... Success!
(driver `to-be-written')
Intel Core family thermal sensor... No
Intel AMB FB-DIMM thermal sensor... No

Now follows a summary of the probes I have just done. Just press ENTER to continue:

Driver `it87' (should be inserted):
Detects correctly:
* ISA bus, address 0x228
Chip `ITE IT8716F Super IO Sensors' (confidence: 9)

Driver `to-be-written' (should be inserted):
Detects correctly:
* Chip `AMD K10 thermal sensors' (confidence: 9)

I will now generate the commands needed to load the required modules. Just press ENTER to continue:

To load everything that is needed, add this to /etc/modules:

#----cut here----
# Chip drivers
it87

# no driver for AMD K10 thermal sensors yet
#----cut here----

Do you want to add these lines automatically? (yes/NO)

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

#32 lore raw
In reply to Achim Gottinger

Hi Achim,

Quoted 10 lines · achim

He He, the BKDG is tough to read. I tried to figure out the SMbus adresses.

http://www.abload.de/image.php?imgºredit-sidebandeis.jpg

This is the register where the adress should be in bits 4:6 whom are all zero. However bit 3 is set and that should mean that the sideband interface is used.

http://www.abload.de/image.php?img=sidebandumy.jpg

This isn't how I read the specification. Bit 3 set means that the SBI is _disabled_. But it your case, bit 3 is _not_ set, is it?

I wonder where the 4 higher SMBus address bits are set.

Quoted 9 lines

(...)
Thank you for the tip. But under linux only the address space from 0x00-0xFF is accesible thru /proc/bus/pci...
I tried to access 0x1E4 that way

setpci -s 0:18.3 0x1E4.l

and only got 0xFFFFFFFF back. Same happens if i try to read from /proc/bus/pci/00/18.3 direct (with a small python script).

Ah, I didn't know.

Quoted 8 lines

I tried to read out 0x6e with the -r option. It is possible to read the following areas without making the smbus controler nonfunctional. 0x00-0x7F,
0x80-0x9d,0xa0-0xbd,0xc0-0xdd,0xe0-0xfd

ALso i tried to run sensors-detect with excluding 0x2e,0x6e and 0x47. It passed but afterwards I had to restart to get rid of the XX'es in the i2cdump.

So there must be yet another chip which doesn't like being probed. This confirms my impression that the safest fix is to blacklist the motherboard and disable the SMBus entirely. Although I understand that you don't want to do this now, as you are still investigating.

Signature · 6 lines
Jean Delvare

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
#33 lore raw
In reply to Achim Gottinger
Quoted 13 lines · Jean Delvare

Hi Achim,

Quoted 9 lines · achim

He He, the BKDG is tough to read. I tried to figure out the SMbus adresses.

http://www.abload.de/image.php?imgºredit-sidebandeis.jpg

This is the register where the adress should be in bits 4:6 whom are all zero. However bit 3 is set and that should mean that the sideband interface is used.

Quoted 9 lines
Quoted 2 lines

http://www.abload.de/image.php?img=sidebandumy.jpg

This isn't how I read the specification. Bit 3 set means that the SBI is _disabled_. But it your case, bit 3 is _not_ set, is it?

I wonder where the 4 higher SMBus address bits are set.

Yepp it's unset means SBI is enabled. Can be a bios issue that the correct address does not shop up here.
That board also does strange things with the cpu and nb vid. No matter what i set in the bios the current-p-state register allways shows 1.3V. The sensor-chip reads the correct values.
The voltage register works to set p-states. I tweaked the p-state-0 and p-state-1 registers once in a way that CnQ worked with 400MHz at 0.8V in idle and 2.6GHz at 1.4V under load. With CnQ enabled it uses the vid's from those two registers (per cpu).

I'd love to get the readings of those SVI SMbus interfaces. That way it should be possible to read the current northbridge (on chip) voltage, whom is not accessible via the sensor-chip and i can verify that voltage only with an DMM at the moment.

Quoted 4 lines

So there must be yet another chip which doesn't like being probed. This confirms my impression that the safest fix is to blacklist the motherboard and disable the SMBus entirely. Although I understand that you don't want to do this now, as you are still investigating

It's i2cdetect 0 itself. I need to reboot after i ran this to dump the special chips. Otherwise I only get XX's. This issue only occures with the phenom and not with the X2 cpu.
All chips beside those at 0x2e,0x47 and 0x6e can be fully dumped without causing the XX-issue.
Today I wrote a long problem report for the sapphire support and asked them what chip they use at 0x2e. Hope they will shed some light on this issue.
I'll post their response here.

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

#34 lore raw
In reply to Achim Gottinger
Quoted 4 lines · Rudolf Marek

ICS is now part of IDT. They sent to me the datasheet for my clockchip, quite fast. Please just make sure you read the chip labels correctly and I can try to write them once we know 100% that the chip names matches reality. I sometimes take a macro pictures of the chips instead of using magnifier.

A guy at IDT just sent me the datasheet for the ICS9LPRS477C. It is a clock chip living at 0x69 and it uses SMBus block mode. So it's definitely not the mysterious chip at 0x2e...

Signature · 6 lines
Jean Delvare

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
#35 lore raw
In reply to Achim Gottinger

Hi Achim,

Quoted 17 lines · Achim Gottinger
Quoted 16 lines · Jean Delvare

Hi Achim,

Quoted 11 lines · achim

He He, the BKDG is tough to read. I tried to figure out the SMbus adresses.

http://www.abload.de/image.php?imgºredit-sidebandeis.jpg

This is the register where the adress should be in bits 4:6 whom are all zero. However bit 3 is set and that should mean that the sideband interface is used.

http://www.abload.de/image.php?img=sidebandumy.jpg

Quoted 8 lines
Quoted 6 lines

This isn't how I read the specification. Bit 3 set means that the SBI is _disabled_. But it your case, bit 3 is _not_ set, is it?

I wonder where the 4 higher SMBus address bits are set.

Yepp it's unset means SBI is enabled. Can be a bios issue that the correct address does not shop up here.

What makes you think it doesn't? If I read it correctly, the BKDG says:
if the address is unset/unused then these bits are 0; it doesn't say:
if these bits are 0 it means that the address is unset/unused. It is perfectly valid for the 3 low bits of an I2C address to be 0. Ideally you would find in the datasheet what the other address bits are (I guess they are hard-coded.) Note that we've seen a chip at 0x70 on your SMBus and we don't know what it is. That could be it, as its 3 low address bits at 0.

Quoted 10 lines
Quoted 4 lines

So there must be yet another chip which doesn't like being probed. This confirms my impression that the safest fix is to blacklist the motherboard and disable the SMBus entirely. Although I understand that you don't want to do this now, as you are still investigating

It's i2cdetect 0 itself. I need to reboot after i ran this to dump the special chips. Otherwise I only get XX's. This issue only occures with the phenom and not with the X2 cpu.
All chips beside those at 0x2e,0x47 and 0x6e can be fully dumped without causing the XX-issue.

Given that we see a chip at 0x70, the bus has to be alive until then, so the i2cdetect probe breaking the bus must be with address >= 0x70. Some chips don't like the quick command we use by default for probing. You might try "i2cdetect -r" and see if it helps. You can also try the extra range parameters to probe the addresses one by one, that way you can find out which one exactly breaks the bus when probed.

Quoted 4 lines

Today I wrote a long problem report for the sapphire support and asked them what chip they use at 0x2e. Hope they will shed some light on this issue.
I'll post their response here.

Thank you.

Signature · 6 lines
Jean Delvare

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
author
#36 lore raw
In reply to Achim Gottinger

Am Dienstag, den 06.05.2008, 16:11 +0200 schrieb Jean Delvare:

Quoted 7 lines

Hi Achim,

Quoted 5 lines
Quoted 5 lines
Quoted 1 line

This isn't how I read the specification. Bit 3 set means that the SBI is _disabled_. But it your case, bit 3 is _not_ set, is it?

Quoted 7 lines
Quoted 5 lines
Quoted 3 lines

I wonder where the 4 higher SMBus address bits are set.

Yepp it's unset means SBI is enabled. Can be a bios issue that the correct address does not shop up here.

What makes you think it doesn't?

Simple answer, lack of basic knowledge about i2c/smbus here.

Quoted 8 lines

If I read it correctly, the BKDG says:
if the address is unset/unused then these bits are 0; it doesn't say:
if these bits are 0 it means that the address is unset/unused. It is perfectly valid for the 3 low bits of an I2C address to be 0. Ideally you would find in the datasheet what the other address bits are (I guess they are hard-coded.) Note that we've seen a chip at 0x70 on your SMBus and we don't know what it is. That could be it, as its 3 low address bits at 0.

Now with that information i compared dumps of 0x70 at idle and load and the really differ, even slightly in idle. It is a temperature sensor. This interface is also there with the k8 cpu. However such an interface is not mentioned in the BKDG for K8. Can be it's a sensor for the pwm area.

I figured out that the interface at 0x4c is the svi interface. I compared dumps with different cpu and northbridge voltages and both make a difference.

Quoted 6 lines

Given that we see a chip at 0x70, the bus has to be alive until then, so the i2cdetect probe breaking the bus must be with address >= 0x70. Some chips don't like the quick command we use by default for probing. You might try "i2cdetect -r" and see if it helps. You can also try the extra range parameters to probe the addresses one by one, that way you can find out which one exactly breaks the bus when probed.

Thanks I tried the range 0x71-0x77 and there where no other chips.

Quoted 6 lines
Quoted 5 lines

Today I wrote a long problem report for the sapphire support and asked them what chip they use at 0x2e. Hope they will shed some light on this issue.
I'll post their response here.

A collegue of mine tried i2cdetect 0 on his Abit AX78 (770 chipset, SB600, and a w83627ehf sensor-chip. On his board it's the sensor chip at 0x2e if i read the log file correct.
He's using an Phenom 9850BE and does not get the interfaces at 0x4c, 0x57. Also he has no interface at 0x70.

Quoted 46 lines
# sensors-detect revision 5016 (2007-11-11 22:20:16 +0100)
Next adapter: SMBus PIIX4 adapter at 0b00 (i2c-0)
Client found at address 0x2e
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Probing for Super-I/O at 0x2e/0x2f
Trying family `VIA/Winbond/Fintek'... Yes
Found `Winbond W83627DHG Super IO Sensors' Success!
(address 0x290, driver `w83627ehf')
AMD K10 thermal sensors... Success!
(driver `to-be-written')
Driver `w83627ehf' (should be inserted):
Detects correctly:
* ISA bus, address 0x290
Chip `Winbond W83627DHG Super IO Sensors' (confidence: 9)
Driver `to-be-written' (should be inserted):
Detects correctly:
* Chip `AMD K10 thermal sensors' (confidence: 9)
$ i2cdetect -l
Code:
i2c-0	unknown   	SMBus PIIX4 adapter at 0b00     	N/A
$ sudo i2cdetect 0
Code:
0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 2e -- 
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --
$ sudo i2cdump 0 0x2e
Code:
0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: c5 0f 00 00 00 00 00 c0 14 62 ff ff ff ff ff ff    ??.....??b......
10: 02 00 00 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    ................
Quoted 8 lines
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    ................

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

#37 lore raw
In reply to Achim Gottinger
Quoted 5 lines · achim

Now with that information i compared dumps of 0x70 at idle and load and the really differ, even slightly in idle. It is a temperature sensor. This interface is also there with the k8 cpu. However such an interface is not mentioned in the BKDG for K8. Can be it's a sensor for the pwm area.

There are lots of things which can change between idle and load, not just temperature.

Quoted 3 lines

I figured out that the interface at 0x4c is the svi interface. I compared dumps with different cpu and northbridge voltages and both make a difference.

Ah, I get it now. Apparently address bit 2 is inverted, so 000b in the register, means that the I2C address ends up in 100b. Which is the case of 0x4c (1001100b). This suggests that the hard-coded part of the address is 1001b for the 4 most-significant bits.

Quoted 26 lines

A collegue of mine tried i2cdetect 0 on his Abit AX78 (770 chipset, SB600, and a w83627ehf sensor-chip. On his board it's the sensor chip at 0x2e if i read the log file correct.
He's using an Phenom 9850BE and does not get the interfaces at 0x4c, 0x57. Also he has no interface at 0x70.

Quoted 20 lines
# sensors-detect revision 5016 (2007-11-11 22:20:16 +0100)
Next adapter: SMBus PIIX4 adapter at 0b00 (i2c-0)
Client found at address 0x2e
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Probing for Super-I/O at 0x2e/0x2f
Trying family `VIA/Winbond/Fintek'... Yes
Found `Winbond W83627DHG Super IO Sensors' Success!
(address 0x290, driver `w83627ehf')
AMD K10 thermal sensors... Success!
(driver `to-be-written')
Driver `w83627ehf' (should be inserted):
Detects correctly:
* ISA bus, address 0x290
Chip `Winbond W83627DHG Super IO Sensors' (confidence: 9)
Driver `to-be-written' (should be inserted):
Detects correctly:
* Chip `AMD K10 thermal sensors' (confidence: 9)

This is incomplete so it is impossible to say if there's a sensor chip or something else at SMBus address 0x2e. While it is a common address for sensor chips, we've seen on your board that other chips can live there. But I doubt it, as the Super-I/O chips has sensors, too.

Quoted 26 lines
Quoted 26 lines
$ i2cdetect -l
Code:
i2c-0	unknown   	SMBus PIIX4 adapter at 0b00     	N/A
$ sudo i2cdetect 0
Code:
0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 2e -- 
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --
$ sudo i2cdump 0 0x2e
Code:
0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: c5 0f 00 00 00 00 00 c0 14 62 ff ff ff ff ff ff    ??.....??b......
10: 02 00 00 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    ................
Quoted 8 lines
Quoted 8 lines
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    ................

Doesn't look like anything I know. But it also doesn't seem to be the same chip as you have on your own boards.

Signature · 6 lines
Jean Delvare

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
#38 lore raw
In reply to Achim Gottinger
Quoted 34 lines · Jean Delvare
Quoted 25 lines
Quoted 25 lines
$ i2cdetect -l
Code:
i2c-0	unknown   	SMBus PIIX4 adapter at 0b00     	N/A
$ sudo i2cdetect 0
Code:
0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 2e -- 
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --
$ sudo i2cdump 0 0x2e
Code:
0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: c5 0f 00 00 00 00 00 c0 14 62 ff ff ff ff ff ff    ??.....??b......
10: 02 00 00 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    ................
Quoted 8 lines
Quoted 8 lines
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    ................
Quoted 3 lines

Doesn't look like anything I know. But it also doesn't seem to be the same chip as you have on your own boards.

I have on my ASUS motherboard an TPM chip at 0x4e as example , sensors-detect thinks is an SMSC chip with unknow ID 0x0b00.

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

#39 lore raw
In reply to Achim Gottinger
Quoted 36 lines · Gabriel C
Quoted 34 lines · Jean Delvare
Quoted 33 lines
Quoted 33 lines
$ i2cdetect -l
Code:
i2c-0	unknown   	SMBus PIIX4 adapter at 0b00     	N/A
$ sudo i2cdetect 0
Code:
0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 2e -- 
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --
$ sudo i2cdump 0 0x2e
Code:
0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: c5 0f 00 00 00 00 00 c0 14 62 ff ff ff ff ff ff    ??.....??b......
10: 02 00 00 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    ................
Quoted 6 lines
Quoted 3 lines

Doesn't look like anything I know. But it also doesn't seem to be the same chip as you have on your own boards.

I have on my ASUS motherboard an TPM chip at 0x4e as example , sensors-detect thinks is an SMSC chip with unknow ID 0x0b00.

Totally unrelated... We're talking about _SMBus_ addresses, you're talking about _LPC_ (I/O) addresses. The fact that the address number is the same (0x4e) is a coincidence.

Signature · 6 lines
Jean Delvare

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors