**Unified** DFI LanParty UT 790FX-M2R-M2RS / Phenom /Data Base Thread**

[justapost]

Thanks for the details Achim

You are welcome. Actualy I'm having quite alot of fun dumping i2c/smbus devices.
May I ask you for a test. Can you install i2c-tools "modprobe i2c-dev" and run
"i2cdetect -l" first. It should find an SMBUSPIIX compatible device as i2c-0.
"i2cdetect 0" will then scann this device for chips.
I get those results on the sapphire board with different cpu's

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

The device at 0x2e is causing the trouble here. 0x38 can be eighter the SB or related to the clock generator whom is at 0x69. Gotta decrypt that output of 0x69, it changes with bios changes for ref HT, pcie speed and spread spectrum.
0x50-0x53 are the DIMM's i did not try to read those.
0x6e is an pcie chip whom does not exist on the gbt780g and the m3a.

It is possible to readout some of those chips with "i2cdump 0 0x38" for example.
Do not run that for 0x2e on the DFI Lanparty UT 790FX or NF4!
Dumping 0x6e stopps at 0x9e and afterwards a coldstart is required to get the smbus chip working again. 0x47 also requires an coldstart after i tried to read that chip.
It was save to dump 0x38,0x4c, 0x4e, 0x57 and 0x70.
I'd be interested in the output of 0x38. I expect with an phenom cpu you'll also the 0x4c, 0x47 and 0x57. I skimmed ovr the BKDG and it seems the cpu has smbus interfaces for voltages and thermal sensors.

[AlabamaCajun]

I finally got to 2.61G using 12.5x209. There seems to be a number of issues with these bioses. RAM TRC stops at 26 and I see this with all the boards. Most dims will run 26 up to about 840 above that they need more but the BIOS locks it at 26. The GA790FX had the same problem and caused the major part of the instability.

The other issue I see is after setting the CPU multi. I can lower it just like the Locked CPUs but can't raise it above 12.5. Does this board not know this is a BE version?

[Brother Esau]

What Bios are you on Alabama? Also to I might add if you use the Template I provide with my settings using Hex Code versus the HT Mutiplier set you will find or at least in my experience the Bios and Board responds better to having the Multi set that way versus the HT Mutiplier.

[AlabamaCajun]

I'm on 416 and back to 205x12.5 every thing else at stock except VCore and NB locked at 1.28V.

[justapost]

A sidenote: I tried the downcore register and it worked. Above screenshot shows the settings i used to disable core 3 and 4. After a reboot (warmstart) I'm on a dualcore system now.
I think tictac mentioned it a few moth ago and KTE tried it on the MSI where it did not work.

[justapost]

You are welcome. Actualy I'm having quite alot of fun dumping i2c/smbus devices.
May I ask you for a test. Can you install i2c-tools "modprobe i2c-dev" and run
"i2cdetect -l" first. It should find an SMBUSPIIX compatible device as i2c-0.
"i2cdetect 0" will then scann this device for chips.
I get those results on the sapphire board with different cpu's

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

The device at 0x2e is causing the trouble here. 0x38 can be eighter the SB or related to the clock generator whom is at 0x69. Gotta decrypt that output of 0x69, it changes with bios changes for ref HT, pcie speed and spread spectrum.
0x50-0x53 are the DIMM's i did not try to read those.
0x6e is an pcie chip whom does not exist on the gbt780g and the m3a.

It is possible to readout some of those chips with "i2cdump 0 0x38" for example.
Do not run that for 0x2e on the DFI Lanparty UT 790FX or NF4!
Dumping 0x6e stopps at 0x9e and afterwards a coldstart is required to get the smbus chip working again. 0x47 also requires an coldstart after i tried to read that chip.
It was save to dump 0x38,0x4c, 0x4e, 0x57 and 0x70.
I'd be interested in the output of 0x38. I expect with an phenom cpu you'll also the 0x4c, 0x47 and 0x57. I skimmed ovr the BKDG and it seems the cpu has smbus interfaces for voltages and thermal sensors.

I forgott one thing the output of dmidecode for different boards would be great.

[KTE]

Thanks for that try Achim... I'll try it out on the Abit next
Yep MSI w/9600BE did not do it.

[Brother Esau]

"New" D.F.I LanParty UT 790FX-M2R ~ 5/5/2008 ~ "Beta" Bios..........http://www.dfi.com.tw/Support/Downlo...FLAG=B&SITE=US

[SteveLord]

Noice.

[aGeoM]

A sidenote: I tried the downcore register and it worked. Above screenshot shows the settings i used to disable core 3 and 4. After a reboot (warmstart) I'm on a dualcore system now.
I think tictac mentioned it a few moth ago and KTE tried it on the MSI where it did not work.

Thanks man, it worked , however 1st core can't be disabled.

[ozlacs]

My 9850BE just stopped working. This time lm-senors detect was the cause. I booted the board with an 5000BE flashed the Bios and cleared the DMI area. But no louck with the 9850BE, stuck at C1, even with DDR2-800 memory. The 9600BE works.

I've a Phenom 9850 with a DFI M2R and I'm using linux as main OS.
I have not tried yet to run lm-sensor detect on this new system, and now I am concerned to read this

but the Phenom is really dead?
which distro you used? which version of kernel? and which version of lm-sensors? thanks!


ps: hi to all, greetings from Italy!

[aGeoM]

"New" D.F.I LanParty UT 790FX-M2R ~ 5/5/2008 ~ "Beta" Bios..........http://www.dfi.com.tw/Support/Downlo...FLAG=B&SITE=US

Thanks man, still hot...

OK:
MEM Voltage read correctly at 2.19, 2.22 reads 2.24
HT Link speed still broken
...testing

[justapost]

Thanks for that try Achim... I'll try it out on the Abit next
Yep MSI w/9600BE did not do it.

Thanks man, it worked , however 1st core can't be disabled.

The first core is used to configure the other cores during bootup, I guesst that's why he can't be disabled.
DFI should add a field for the other three cores, so they can be disabled individual. M3A only allows to specify the number for cores you want to use but does not let you choose which ones.

I've a Phenom 9850 with a DFI M2R and I'm using linux as main OS.
I have not tried yet to run lm-sensor detect on this new system, and now I am concerned to read this

but the Phenom is really dead?
which distro you used? which version of kernel? and which version of lm-sensors? thanks!

ps: hi to all, greetings from Italy!

Welcome to XS.

I used Debian testing/lenny with an 2.6.24 kernel and lm-sensors version 3.0.1. Jean from the lm-sensor team already wrote an patch whom disables the smbus scannig on the DFI and Sapphire versions of the board.
You can simply avoid running sensors-detect and add those two modules to your modules.conf "i2c-piix4" and "it87". Both work fine and sensors shows all the voltages / temepraturs and fan speeds the sensor chip has to offer.

My chip is really dead, however it might have been a coincidence that the chip died from the sensors scan. I guess the chip at address 0x2e is a write-only device so a read probe might cause that chip to change voltages or frequencies in an unexpected way. My theorie is that all those apps utilising the smbus run similar detection routines and that might cause some voltage or frequency spikes whom damage the processor over long time. I asked the sapphire support today what chip that is at 0x2e. I hope i get the specs so i can figure out what the probe routine exactly did.

[KTE]

Hmm.. I used a few programs which detect sensors.
Ones that used old sensors or buses were the ones to BSOD my system, but never kill.

Anyone tried Intels Linux Power tool?
I'm going to try it out next.

Good news for me BTW

EDIT: saw your reply above now

Yes, physically core0 can never be disabled, everything uses it.
Achim, this is what Abit uses for scanning parameters: http://www.xtremesystems.org/forums/...&postcount=252

[justapost]

Hmm.. I used a few programs which detect sensors.
Ones that used old sensors or buses were the ones to BSOD my system, but never kill.

Anyone tried Intels Linux Power tool?

You mean their tool to detect uneconomic coded parts in programs? Or is that a tool to tweak kernel parameters?

As i said above can be that this spike caused my already weak cpu to fail. Gotta wait for the sappire response now.

Achim, this is what Abit uses for scanning parameters: http://www.xtremesystems.org/forums/...&postcount=252

Those are the adresses where the sensor chip holds those infos?
I'd need a list of smbus devices. The smbus chip is a part of the SB600/700 i guess. sensors-detect finds the SB600 here and uses the i2c-piix4 module for the smbus component.

"i2cdetect -l" shows that chip at i2c-0 here. The chip is accessible thru /dev/i2c-0 after you loaded the i2c-dev module.

"i2cdetect 0" probes what adresses have chips behind but does not run read probes on those adresses.

I assume you will get at least 0x38, 0x69, 0x50-0x53 (depends on the numer of dimms you use). On a crossfire board also 0x6e should show up.
The chips at 0x2e and 0x4e are there on the DFI 790FX and the DFI NF4. 0x2e is the troublemaker.

Today i found that even the "i2cdetect -l" makes the smbus chip unusable till i restart (it does not freeze or reboot the system but i can not read out the chips with "i2cdump 0 0x69" i only get XX's as results.
This issue only occures with an phenom mounten and not with an X2 chip.
With a phenom mounten there are also smbus interfaces at 0x57 and 0x4c.

The BKDG says the cpu uses smbus interfaces for svi and also for a side band interface to the temperature sensor. They refer to a special document about that sideband interface which i can not find at amd's website.

I plan to ask their support for the specs of those smbus interfaces. I'd like to read the cpu and nb voltages thru the svi interface.

[Brother Esau]

Has anyone else installed the 5/5/2008 Beta Bios besides Ageom and Myself?

[KTE]

You mean their tool to detect uneconomic coded parts in programs? Or is that a tool to tweak kernel parameters?

It checks what consumes most CPU usage and power... PowerTOP I think. Installing Etch now, so will check it out.

Those are the adresses where the sensor chip holds those infos?

Where ABit utilities and BIOS access those infos, yes.

I'd need a list of smbus devices. The smbus chip is a part of the SB600/700 i guess. sensors-detect finds the SB600 here and uses the i2c-piix4 module for the smbus component.

"i2cdetect -l" shows that chip at i2c-0 here. The chip is accessible thru /dev/i2c-0 after you loaded the i2c-dev module.

"i2cdetect 0" probes what adresses have chips behind but does not run read probes on those adresses.

I assume you will get at least 0x38, 0x69, 0x50-0x53 (depends on the numer of dimms you use). On a crossfire board also 0x6e should show up.
The chips at 0x2e and 0x4e are there on the DFI 790FX and the DFI NF4. 0x2e is the troublemaker.

To be honest, I have no extra time to play about, I'm just managing to test it, barely, and that takes all my spare time
I'll boot into Ubuntu and check the addresses out but I'm really wary after your CPU kill with those accesses. Your board is different to mine, lm-sensors never worked for me at all apart from ACPI temp but its not necessary what killed yours kills mine - something else may kill mine, so I'm limiting what I checkout.

Today i found that even the "i2cdetect -l" makes the smbus chip unusable till i restart (it does not freeze or reboot the system but i can not read out the chips with "i2cdump 0 0x69" i only get XX's as results.
This issue only occures with an phenom mounten and not with an X2 chip.
With a phenom mounten there are also smbus interfaces at 0x57 and 0x4c.

The BKDG says the cpu uses smbus interfaces for svi and also for a side band interface to the temperature sensor. They refer to a special document about that sideband interface which i can not find at amd's website.

I plan to ask their support for the specs of those smbus interfaces. I'd like to read the cpu and nb voltages thru the svi interface.

I've never seen any mention of them to date and I have the docs. Officially, this all there is in the documentation regarding SMBus on functions I've seen - I'l post it in Abit thread when I get a chance if you haven't seen it already.
Thanks for the search and info though!

[AlabamaCajun]

1,2 and 4 I'm going to give it a shot because of the DRAM fix, TRFC.
3. Right, I'm going to stick a Sempron in a $250 USD board Maybe one of those 2100 Dulies. Think it would go from 1.8 to 3.6 and beat a Penryn :ssplllt:

Major Reasons of Change:
1. Fixed DRAM timing show error.
2. Change detect SPD Function for TRFC.
3. Fixed Sempron CPU Can't into CMOS setup.
4. Fixed BIOS DRAM Voltage detecting error.

Update :p Nothing new for me. I tried at 1.6275V which is what I expected to be able to do 2.6 but BIOS drops back to 2.5G and HTT at 207 Crashes. I'll try getting it cooler and 1.32V which I can get 2.7G but that sucks. I may just be stick with a ed up chip.

[KTE]

AC that's the worst 9850 I've heard of so far, really, very poor - unless there's something else to it.
Not sure how exactly you're trying but your board has many compatibility problems so the first thing I would do is take one stick of RAM out, throw tRFC 195ns and then try seeing what the core can get to stable. Then throw the second stick back in and check.

In my case RAM limits the oc a lot and yep, tRFC is central to Phenom oc and stability. I have no boot at 800 4-4-4-12-23 105ns 2.1v whilst on the Intel platform I can get 1200 5-5-5-15 2.15v stable out of them. Minimum stable boot requires 127.5ns tRFC here with ProMOS and Elpida ICs. Microns do better.

[Sadhiq]

Hi,

Here's a little review I wrote two months ago : http://www.jmax-hardware.com/article...790fx-m2r.html

I'll now use it for my H24 rig with a 6400+ cpu... Hope to get a 9850 BE for testing but it doesn't look like it will happen

[Rammsteiner]

I tried autoclock once too and I got to 207 too. 2.7Ghz eventually froze my system btw...

[Tony]

Testing the bios now, 1.8V got me 1.84 on the MM which is a lot better than 1.9V+ as it used to be.

Also I have an answer for the flashing cursor and blue bar issue, it seems a slight corruption in cmos reloaded may be the cause, im trying to get either an option added to bios to clear all cmos reloaded data or the tool to write 0's to it like F-Tester.exe we used on the MF4 chipsets.

[Brother Esau]

Testing the bios now, 1.8V got me 1.84 on the MM which is a lot better than 1.9V+ as it used to be.

Also I have an answer for the flashing cursor and blue bar issue, it seems a slight corruption in cmos reloaded may be the cause, im trying to get either an option added to bios to clear all cmos reloaded data or the tool to write 0's to it like F-Tester.exe we used on the MF4 chipsets.

@Tony.....its really great that you are on board with this on the Bios level as we desperately need your expertise and direct tie to D.F.I so we can get the advancement thats needed on this pending and ongoing issue .

Thank you very much for devoting you're time and attention to helping us we and I sure do appreciate you're involvement and time

Campbell

[AlabamaCajun]

Testing the bios now, 1.8V got me 1.84 on the MM which is a lot better than 1.9V+ as it used to be.

Also I have an answer for the flashing cursor and blue bar issue, it seems a slight corruption in cmos reloaded may be the cause, im trying to get either an option added to bios to clear all cmos reloaded data or the tool to write 0's to it like F-Tester.exe we used on the MF4 chipsets.

OK, I saw that last night and blew it off as instability.

AC that's the worst 9850 I've heard of so far, really, very poor - unless there's something else to it.
Not sure how exactly you're trying but your board has many compatibility problems so the first thing I would do is take one stick of RAM out, throw tRFC 195ns and then try seeing what the core can get to stable. Then throw the second stick back in and check.

In my case RAM limits the oc a lot and yep, tRFC is central to Phenom oc and stability. I have no boot at 800 4-4-4-12-23 105ns 2.1v whilst on the Intel platform I can get 1200 5-5-5-15 2.15v stable out of them. Minimum stable boot requires 127.5ns tRFC here with ProMOS and Elpida ICs. Microns do better.

As long as I leave the RAM at 800, I'm solid as a rock. I can drop ram to 667 and clock up ok but limited by the CPU. I can run the RAM to about 840 before the TRC gets to short at 26 in order to complete the refresh cycle. It's bases on time. When you increase freq. the time spent waiting for refresh is shortened but the physics of the RAM require that time in m/secs to get through the cycle. I don't know why no one in the industry will listen to this. Either fix the mobos so we can set 900, 1000, 1100 etc or fix the RAM tables so that the correct settings are in place when we adjust timings to meet these standards. All the people making these toys need to get it together. I'm getting tired of spending money only to find it won't work with this or that part.

CPU speed is another issue. I'm voltage and thermal limited. Below 1.25 I can't go over 2520 or so. I need 1.29 to get 2.6G fairly stable. 1.32 to go to 2.7G. Above 2.6G the heat rises about 60C which means thermal instability. I need to find a sink that performs better than the Ninja which has been the best so far.

I'm looking at 3 options. Get a better Air sink, I've though of water but it's a maintenance issue and a pain.
Leave it at Stock until we get more results or can resolve the issue but continue to experiment on occasion.
Put the 5600 back in and use the Kentsfield for quad work.

[KTE]

I'd need a list of smbus devices. The smbus chip is a part of the SB600/700 i guess. sensors-detect finds the SB600 here and uses the i2c-piix4 module for the smbus component.

"i2cdetect -l" shows that chip at i2c-0 here. The chip is accessible thru /dev/i2c-0 after you loaded the i2c-dev module.

"i2cdetect 0" probes what adresses have chips behind but does not run read probes on those adresses.

I assume you will get at least 0x38, 0x69, 0x50-0x53 (depends on the numer of dimms you use). On a crossfire board also 0x6e should show up.
The chips at 0x2e and 0x4e are there on the DFI 790FX and the DFI NF4. 0x2e is the troublemaker.

0x2e is SPD EEPROM on mine.

# 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

i2c-0	unknown   	SMBus PIIX4 adapter at 0b00     	N/A

$ sudo i2cdetect 0

     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

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

Today i found that even the "i2cdetect -l" makes the smbus chip unusable till i restart (it does not freeze or reboot the system but i can not read out the chips with "i2cdump 0 0x69" i only get XX's as results.
This issue only occures with an phenom mounten and not with an X2 chip.
With a phenom mounten there are also smbus interfaces at 0x57 and 0x4c.

Mine seem to be similar with a few differences but I'm on SB600 not SB700 and 770 chipset. HIH