[lm-sensors] sensors-detect killed my CPU

[lm-sensors] sensors-detect killed my CPU

[Achim Gottinger]

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
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] sensors-detect killed my CPU

[Jean Delvare]

Hi Achim,

On Fri, 02 May 2008 23:18:18 +0200, Achim Gottinger wrote:
> 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.

-- 
Jean Delvare

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

Re: [lm-sensors] sensors-detect killed my CPU

[Ruzicka Pavel]

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

> 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
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors



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

Re: [lm-sensors] sensors-detect killed my CPU

[achim]

[-- Attachment #1: Type: text/plain, Size: 3412 bytes --]

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~

> 
> 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.
> 

[-- Attachment #2: sapphire-790FX-dmidecode.txt --]
[-- Type: text/plain, Size: 17444 bytes --]

# 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


[-- Attachment #3: sapphire-790FX-lspci-nnv.txt --]
[-- Type: text/plain, Size: 12347 bytes --]

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


[-- Attachment #4: Type: text/plain, Size: 153 bytes --]

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

Re: [lm-sensors] sensors-detect killed my CPU

[Jean Delvare]

On Sat, 03 May 2008 17:27:34 +0200, achim wrote:
> 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.

> 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.

>                                             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 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.

> 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.

> 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.

> 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.

> 
> 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.

> 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.

-- 
Jean Delvare

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

Re: [lm-sensors] sensors-detect killed my CPU

[achim]

Am Samstag, den 03.05.2008, 18:27 +0200 schrieb Jean Delvare:
> On Sat, 03 May 2008 17:27:34 +0200, achim wrote:
> > 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.
> 
> > 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.

> 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. 

> 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.
> 

> I guess it's a typo and you mean IT8716F-S.
Yepp, typo
> 
> > 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?

Nothing I was just unsure what module caused the freeze.

> 
> 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
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[PATCH] i2c-piix4: Blacklist the Sapphire AM2RD790 motherboard

[Jean Delvare]

On Sat, 3 May 2008 18:27:01 +0200, Jean Delvare wrote:
> 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.

Signed-off-by: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
---
 drivers/i2c/busses/i2c-piix4.c |   25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

--- linux-2.6.25.orig/drivers/i2c/busses/i2c-piix4.c	2008-04-19 11:11:56.000000000 +0200
+++ linux-2.6.25/drivers/i2c/busses/i2c-piix4.c	2008-05-03 19:32:46.000000000 +0200
@@ -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 "

-- 
Jean Delvare

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

[lm-sensors] [PATCH] i2c-piix4: Blacklist the Sapphire AM2RD790

[Jean Delvare]

On Sat, 3 May 2008 18:27:01 +0200, Jean Delvare wrote:
> 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.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
---
 drivers/i2c/busses/i2c-piix4.c |   25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

--- linux-2.6.25.orig/drivers/i2c/busses/i2c-piix4.c	2008-04-19 11:11:56.000000000 +0200
+++ linux-2.6.25/drivers/i2c/busses/i2c-piix4.c	2008-05-03 19:32:46.000000000 +0200
@@ -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 "

-- 
Jean Delvare

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

Re: [lm-sensors] sensors-detect killed my CPU

[Jean Delvare]

On Sat, 03 May 2008 20:10:23 +0200, achim wrote:
> Am Samstag, den 03.05.2008, 18:27 +0200 schrieb Jean Delvare:  
> > 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.  

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.

> 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.

> 
> 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 ---------------------------------  

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.

> 
> 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.

> > 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?

-- 
Jean Delvare

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

Re: [lm-sensors] sensors-detect killed my CPU

[Jean Delvare]

On Sat, 3 May 2008 21:14:48 +0200, Jean Delvare wrote:
> On Sat, 03 May 2008 20:10:23 +0200, achim wrote:
> > ---------------------------- 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 ---------------------------------  
> 
> 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.
> 
> > 
> > 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.

-- 
Jean Delvare

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

Re: [lm-sensors] sensors-detect killed my CPU

[achim]

Am Samstag, den 03.05.2008, 21:27 +0200 schrieb Jean Delvare:
> On Sat, 3 May 2008 21:14:48 +0200, Jean Delvare wrote:
> > On Sat, 03 May 2008 20:10:23 +0200, achim wrote:
> > > ---------------------------- 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 ---------------------------------  
> > 
> > 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.
> > 
> > > 
> > > 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.
> 
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
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] sensors-detect killed my CPU

[Jean Delvare]

Hallo Achim,

On Sat, 03 May 2008 22:30:46 +0200, achim wrote:
> 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    ................
> ------------------------------------------------------------------------

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.

> #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
> ------------------------------------------------------------------------

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.

> 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.

-- 
Jean Delvare

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

Re: [lm-sensors] sensors-detect killed my CPU

[achim]

[-- Attachment #1: Type: text/plain, Size: 2274 bytes --]


> 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. 

> 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.
> > 

> > > 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..  

> 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.


[-- Attachment #2: sapphire-790FX-dmidecode-dfi-bios.txt --]
[-- Type: text/plain, Size: 17420 bytes --]

# 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


[-- Attachment #3: Type: text/plain, Size: 153 bytes --]

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

Re: [lm-sensors] sensors-detect killed my CPU

[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
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] sensors-detect killed my CPU

[Jean Delvare]

Hi Achim,

On Sun, 04 May 2008 01:24:19 +0200, Achim Gottinger wrote:
> 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

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 :(

> 
> Chip four is something like ICS 7714084.

Couldn't find anything about this one.

> 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.


-- 
Jean Delvare

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

Re: [lm-sensors] sensors-detect killed my CPU

[Jean Delvare]

On Sat, 03 May 2008 23:18:48 +0200, achim wrote:
> > 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.)

>                                        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. 
> 
> > 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.

> > 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.

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

> 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.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
---
 drivers/i2c/busses/i2c-piix4.c |   30 ++++++++++++++++++++++++++++--
 1 file changed, 28 insertions(+), 2 deletions(-)

--- linux-2.6.25.orig/drivers/i2c/busses/i2c-piix4.c	2008-04-19 11:11:56.000000000 +0200
+++ linux-2.6.25/drivers/i2c/busses/i2c-piix4.c	2008-05-04 09:44:42.000000000 +0200
@@ -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 "


-- 
Jean Delvare

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

Re: [lm-sensors] sensors-detect killed my CPU

[Rudolf Marek]

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
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] sensors-detect killed my CPU

[achim]

Am Sonntag, den 04.05.2008, 09:41 +0200 schrieb Jean Delvare:
> Hi Achim,
> 
> On Sun, 04 May 2008 01:24:19 +0200, Achim Gottinger wrote:
> > 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
> 
> 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.

> 
> 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 :(
> 
> > 
> > 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
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] sensors-detect killed my CPU

[achim]

[-- Attachment #1: Type: text/plain, Size: 3169 bytes --]

Am Sonntag, den 04.05.2008, 13:42 +0200 schrieb achim:
> Am Sonntag, den 04.05.2008, 09:41 +0200 schrieb Jean Delvare:
> > Hi Achim,
> > 
> > On Sun, 04 May 2008 01:24:19 +0200, Achim Gottinger wrote:
> > > 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
> > > 
> > > 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.
> 
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.

> 
> > 
> > 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 :(
> > 
> > > 
> > > 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
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[-- Attachment #2: i2cdump-gbt780g-0x38.txt --]
[-- Type: text/plain, Size: 1224 bytes --]

     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??????|?..

[-- Attachment #3: i2cdump-gbt780g-0x69.txt --]
[-- Type: text/plain, Size: 1224 bytes --]

     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

[-- Attachment #4: i2cdump-M3A-0x38.txt --]
[-- Type: text/plain, Size: 1224 bytes --]

     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    ?....@,?.??.|?..

[-- Attachment #5: i2cdump-M3A-0x69.txt --]
[-- Type: text/plain, Size: 1224 bytes --]

     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

[-- Attachment #6: Type: text/plain, Size: 153 bytes --]

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

Re: [lm-sensors] sensors-detect killed my CPU

[Jean Delvare]

Hi Achim,

On Sun, 04 May 2008 14:03:32 +0200, achim wrote:
> Am Sonntag, den 04.05.2008, 13:42 +0200 schrieb achim:
> > Am Sonntag, den 04.05.2008, 09:41 +0200 schrieb Jean Delvare:
> > > Hi Achim,
> > > 
> > > On Sun, 04 May 2008 01:24:19 +0200, Achim Gottinger wrote:
> > > > 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
> > > 
> > > 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.

> > 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.

> > 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.

> > 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 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.
> > 
> 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.

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.

-- 
Jean Delvare

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

[PATCH] i2c-piix4: Blacklist two mainboards

[Jean Delvare]

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.

Signed-off-by: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
---
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(-)

--- linux-2.6.25.orig/drivers/i2c/busses/i2c-piix4.c	2008-04-19 11:11:56.000000000 +0200
+++ linux-2.6.25/drivers/i2c/busses/i2c-piix4.c	2008-05-04 09:44:42.000000000 +0200
@@ -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 "

-- 
Jean Delvare

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: [lm-sensors] sensors-detect killed my CPU

[achim]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1252", Size: 4665 bytes --]

Am Sonntag, den 04.05.2008, 14:39 +0200 schrieb Jean Delvare:
> Hi Achim,
> 
> On Sun, 04 May 2008 14:03:32 +0200, achim wrote:
> > Am Sonntag, den 04.05.2008, 13:42 +0200 schrieb achim:
> > > Am Sonntag, den 04.05.2008, 09:41 +0200 schrieb Jean Delvare:
> > > > Hi Achim,
> > > > 
> > > > On Sun, 04 May 2008 01:24:19 +0200, Achim Gottinger wrote:
> > > > > 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
> > > > 
> > > > 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.
> 
> > > 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.
> 
> > > 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.

> 
> > > 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?
> > > 
> > > 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?


> 
> 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
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

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

[Jean Delvare]

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.

Signed-off-by: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
---
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(-)

--- linux-2.6.25.orig/drivers/i2c/busses/i2c-piix4.c	2008-04-19 11:11:56.000000000 +0200
+++ linux-2.6.25/drivers/i2c/busses/i2c-piix4.c	2008-05-04 09:56:00.000000000 +0200
@@ -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 "

-- 
Jean Delvare

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: [lm-sensors] sensors-detect killed my CPU

[achim]

[-- Attachment #1: Type: text/plain, Size: 4426 bytes --]

> 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.

> 
> > 
> > > > 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?
> > > > 
> > > > 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?
> 
> 
> > 
> > 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
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[-- Attachment #2: i2cdump-0x4c.txt --]
[-- Type: text/plain, Size: 1224 bytes --]

     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    ................

[-- Attachment #3: i2cdump-0x4e.txt --]
[-- Type: text/plain, Size: 1224 bytes --]

     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    ................

[-- Attachment #4: i2cdump-0x38.txt --]
[-- Type: text/plain, Size: 1224 bytes --]

     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    ?....@,?.??.|?..

[-- Attachment #5: i2cdump-0x57.txt --]
[-- Type: text/plain, Size: 1224 bytes --]

     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...

[-- Attachment #6: i2cdump-0x69.txt --]
[-- Type: text/plain, Size: 1224 bytes --]

     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

[-- Attachment #7: i2cdump-0x70.txt --]
[-- Type: text/plain, Size: 1224 bytes --]

     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    ................

[-- Attachment #8: Type: text/plain, Size: 153 bytes --]

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

Re: [lm-sensors] sensors-detect killed my CPU

[Jean Delvare]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1252", Size: 3457 bytes --]

On Sun, 04 May 2008 15:23:23 +0200, achim wrote:
> 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.

> 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.

> 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.

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

Couldn't find how this one is accessed.

> 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?

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.

> 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.

> 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.

-- 
Jean Delvare

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

Re: [lm-sensors] sensors-detect killed my CPU

[Jean Delvare]

On Sun, 04 May 2008 17:27:22 +0200, achim wrote:
> 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.

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 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.

> 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.

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

Yes, it should pass.

> 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.

-- 
Jean Delvare

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

Re: [lm-sensors] sensors-detect killed my CPU

[Achim Gottinger]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1252", Size: 4171 bytes --]

Jean Delvare schrieb:
> On Sun, 04 May 2008 15:23:23 +0200, achim wrote:
>   
>> 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, :)
>  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.
>   
>> 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.
>
>   
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.
>> 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.
>   
>> 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.
>   
Great one unknown chip sorted out. :)
>   
>> 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
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] sensors-detect killed my CPU

[Achim Gottinger]

Jean Delvare schrieb:
> On Sun, 04 May 2008 17:27:22 +0200, achim wrote:
>   
>> 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.
>>     
>
> 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.
>   
>> 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
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] sensors-detect killed my CPU

[Jean Delvare]

On Sun, 04 May 2008 19:47:22 +0200, Achim Gottinger wrote:
> 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).
> ------------------------------------------------------------------------------------------------

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

> 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.)

-- 
Jean Delvare

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

Re: [lm-sensors] sensors-detect killed my CPU

[achim]

[-- Attachment #1: Type: text/plain, Size: 1846 bytes --]

Am Sonntag, den 04.05.2008, 20:16 +0200 schrieb Jean Delvare: 
> On Sun, 04 May 2008 19:47:22 +0200, Achim Gottinger wrote:
> > 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.

> 
> > 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.



[-- Attachment #2: sensors-detect.txt --]
[-- Type: text/plain, Size: 6404 bytes --]

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)


[-- Attachment #3: Type: text/plain, Size: 153 bytes --]

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

Re: [lm-sensors] sensors-detect killed my CPU

[Jean Delvare]

Hi Achim,

On Mon, 05 May 2008 14:15:34 +0200, achim wrote:
> 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.

> (...)
> 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.

> 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.

-- 
Jean Delvare

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

Re: [lm-sensors] sensors-detect killed my CPU

[Achim Gottinger]

Jean Delvare schrieb:
> Hi Achim,
>
> On Mon, 05 May 2008 14:15:34 +0200, achim wrote:
>   
>> 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.
>
>   
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.
> 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
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] sensors-detect killed my CPU

[Jean Delvare]

On Sun, 04 May 2008 10:38:34 +0200, Rudolf Marek wrote:
> 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...

-- 
Jean Delvare

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

Re: [lm-sensors] sensors-detect killed my CPU

[Jean Delvare]

Hi Achim,

On Mon, 05 May 2008 21:44:35 +0200, Achim Gottinger wrote:
> Jean Delvare schrieb:
> > Hi Achim,
> >
> > On Mon, 05 May 2008 14:15:34 +0200, achim wrote:
> >   
> >> 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.
> >
> >   
> 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.

> > 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.

> 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.

-- 
Jean Delvare

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

Re: [lm-sensors] sensors-detect killed my CPU

[achim]

Am Dienstag, den 06.05.2008, 16:11 +0200 schrieb Jean Delvare:
> Hi Achim,
> 
> > >>     
> > >
> > > 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? 

Simple answer, lack of basic knowledge about i2c/smbus here.
> 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. 

> 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.
> 
> > 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.

> # 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    ................
> 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
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] sensors-detect killed my CPU

[Jean Delvare]

On Tue, 06 May 2008 22:44:07 +0200, achim wrote:
> 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.

> 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.

> 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.
> 
> > # 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.

> > 
> > $ 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    ................

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.

-- 
Jean Delvare

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

Re: [lm-sensors] sensors-detect killed my CPU

[Gabriel C]

Jean Delvare wrote:

>>> $ 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    ................
> 
> 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
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] sensors-detect killed my CPU

[Jean Delvare]

On Wed, 07 May 2008 15:02:04 +0200, Gabriel C wrote:
> Jean Delvare wrote:
> 
> >>> $ 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    ................
> > 
> > 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.

-- 
Jean Delvare

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