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

[Rammsteiner]

For me, I change it until AMD PWM and CCPUID read similar. Thats worked fine so far...

ATM, my highest stable is 1.38v 3000/3000/2700/2800 with that method.

Do you mean that when APM and CCPUID read the same speeds, no matter what core number? Like before you had Core #3 on both CCPUID and APM OC'd, reboot and now they both say Core #1, this way it's still correct?

Or if they read Core #1 you change your OC back to default and just try out a different CPU to OC with MSR and continue this untill they both say Core #3 again?

If so, this would mean we've NO clue what core we're actually OC'ing lol. It doesnt matter as long as we're sure we're testing the same core as we tested before though.

If I would have known this earlier I would have written the core # I had with the 2.8Ghz OC

[KTE]

With the Phenom there was a chip at 0x69 whom I dumped many times. I expected it to be the clock generator. I only have the specs for an similar clock generator and I was not yet able to figure it's registers out. I focuesd on the M2A-VM clock generator yesterday, because i have the specs of that clockgen chip and it is the simplest one.

With the k8 cpu there was no chip at 0x69 according to i2cdetect 0. I was curious if that chip was just not detected and tried to dump that address 'i2cdump 0 0x69". It was not the first time i tried to dump an nonexistent address and the result was the same as with other nonexistend address dumps. Just XX's and no hex values.
However after that test "i2cdetect 0" did no longer show the 0x2e chip and since then i can not get beyond C1.

Sad news damn

Most astonishing to me is that AMD PM uses different labels than the MSR-Registers. I thought it completely relies on those registers. M$ developers should shed some light how they bind threads to cores.

I have no idea how they're set

I would love to know how though.

Presumably, I'm thinking, CCPUID/CPUZ/CBID do not change core numbering but AOD/AMD PWM do. I suspect thats what causes the confusion.

But I was running 12.5 multi. Did I say I was running 13.5 multi then? If so, sorry, Im running 12.5.

Yeah it said you were running:

"Voltages were stock, so were VID's. I only changed multi's, first time I did Core #0 14x and the other 3 cores 13x."

Did I misunderstand that?

And KTE, we've the same stepping right. I might add a little Vcore or something then. I just looked at the Phenom stepping/OC thread and it looks like all stepping starting with the 'B' at least do better already. Mine starts with 'A', maybe that's the whole crap thing about.

My reply would've mentioned, that don't look at steppings

Do you mean that when APM and CCPUID read the same speeds, no matter what core number? Like before you had Core #3 on both CCPUID and APM OC'd, reboot and now they both say Core #1, this way it's still correct?

Or if they read Core #1 you change your OC back to default and just try out a different CPU to OC with MSR and continue this untill they both say Core #3 again?

Core0/1 on mine stay put, core2/3 interchange randomly. I can find out by using multiple apps though, tedious procedure.

[justapost]

Sad news damn

Good news, the board is back.

I tried tony's reverse battery method. I left the totaly unplugged board with the clear cmos jumper set and the batter mounted revers alone fopr a few hours and now it's working again. Glad I had luck this time.

[Rammsteiner]

Glad to hear that justapost.

Anyway, was running 3h+ stable, was typing a post here and everything went black and board not responding to reset/power buttons once again. Had to use PSU...

Either Ive a crap chip or my board is really totally borked.

I'd like to believe it's my board, but in the end some people hit 3Ghz with stock Volts. Whether it's 100% stable (ie idle stable), I dont know. But at least their Phenom saw 3Ghz+ in Windows, mine hardly saw 2.9Ghz at any Vcore. Maybe a combination.

So once again, MSR OC'ing didnt bring me anything new. Ill still have to wait for SB750 and/or another Phenom. Oh well, the CPU at stock is fast enough to play Eve-Online so Im fine for a while. Though I really hope to get something started in a month or so.

[justapost]

Glad to hear that justapost.

Thanks, after I got the board working i did a few other tests jean from the lm-seonsors list recommended.

In short at 0x2e lives a chip whom is responsible for vdimm. I can read out that chip with modified i2c-tools.
>i2cget 0 0x2e
0x35
Normaly you can readout an specific register of an chip like this
>i2cget 0 0x2e 0x01
That returns the value of register 0x01 from the chip at 0x2e. Now that chip at 0x2e behaves different. The chip has only one register and
>i2cget 0 0x2e 0x01
results in 0x01 been written into the chips only register and the value is returned. This would mean ~3.2V vdimm.


I figured it out because my system froze as i tried to write 0x32 in that register. After that I had C1's till i removed a dimm. That dimm did not work in the Sapphire board for a while. After i tested it in the gbt board it works again in the sapphire now.
So after i got the board working i measured vdimm with different values in the 0x2e register

0x34 => 1,971V
0x35 => 1,942V
0x36 => 1,916V
0x37 => 1,892V

If an application probes this chip by trying to read address 0x00 the normal way it will result in the highest possible vdimm.

Sidenote: The chip at 0x4c is the cpu's thermal sensor interface. At address 0x01 the core temp can be read out.

Anyway, was running 3h+ stable, was typing a post here and everything went black and board not responding to reset/power buttons once again. Had to use PSU...

Either Ive a crap chip or my board is really totally borked.

I'd like to believe it's my board, but in the end some people hit 3Ghz with stock Volts. Whether it's 100% stable (ie idle stable), I dont know. But at least their Phenom saw 3Ghz+ in Windows, mine hardly saw 2.9Ghz at any Vcore. Maybe a combination.

So once again, MSR OC'ing didnt bring me anything new. Ill still have to wait for SB750 and/or another Phenom. Oh well, the CPU at stock is fast enough to play Eve-Online so Im fine for a while. Though I really hope to get something started in a month or so.

If it helps my 9600BE is not prime95 stable at stock 2.3/1.8GHz 1.25/1.25V.

[vext]

Good news, the board is back.

I tried tony's reverse battery method. I left the totaly unplugged board with the clear cmos jumper set and the batter mounted revers alone fopr a few hours and now it's working again. Glad I had luck this time.

Interesting. My old Epox 939 board used to lock up occasionally. I could shock it back to life by removing the battery, setting the clear cmos jumper for about 10 minutes. Then I would set everything back, and boot up while pressing the insert key. The Epox also had a POST LCD, and would lock up at "FF" rather than "C1".

I recently ran lm-sensors configure while installing Debian Linux on my DFI M2R + 9850BE. It locked everything up and the LED read "C1". I tried my "Epox" technique but it didn't help. I had to RMA both the board and cpu. Since then I've stayed away from lm-sensors and speedfan. Unfortunately those were my two favorite monitoring programs...

If it happens again, I'll try your method. The difference is that you reversed the battery and let it sit for a long time.

[justapost]

I recently ran lm-sensors configure while installing Debian Linux on my DFI M2R + 9850BE. It locked everything up and the LED read "C1". I tried my "Epox" technique but it didn't help. I had to RMA both the board and cpu. Since then I've stayed away from lm-sensors and speedfan. Unfortunately those were my two favorite monitoring programs...

There is no need to run sensors-detect. The only module you need for sensor monitorin is "it87". Seems I have an robus bios chip here.
The second time I ran into the C1 issue, removing one dimm helped. That dimm made problems for a few minutes and seems to work ok now.
The old sensors-detect routine will trigger the chip at 0x2e to appliy an >3V vdimm. That should harm the dimm's and the chip's nb. I wonder why it also results in faulty bioses.
Did you get both RMAed? If so did they say what was defect.

If it happens again, I'll try your method. The difference is that you reversed the battery and let it sit for a long time.

That was tony's tip from a few weeks ago, whom I crossposted here.

[Rammsteiner]

I was just gaming with stock settings. Although I had CnQ and Vcore/Vnb still at auto because of MSR OC attempts. But this shouldnt matter.

But I was gaming and system froze, blackscreen... So I set CnQ off and set the default Vcore and Vnb manually.

If it happens again Ill try to downclock the GPU (maybe the pencil is degrading on it). If not... Im going mad...

Then Ill RMA the M2R and Phenom as well. Im even considering to get Crosshair II instead. This is driving me nuts.

However, not making any conclusions yet. But Im getting a deja vu from my X2 + M2R...

[EDIT]
Didnt help crashed again. Downclocked the GPU this time.

[vext]

There is no need to run sensors-detect. The only module you need for sensor monitorin is "it87". Seems I have an robus bios chip here.
The second time I ran into the C1 issue, removing one dimm helped. That dimm made problems for a few minutes and seems to work ok now.
The old sensors-detect routine will trigger the chip at 0x2e to appliy an >3V vdimm. That should harm the dimm's and the chip's nb. I wonder why it also results in faulty bioses.
Did you get both RMAed? If so did they say what was defect.

That was tony's tip from a few weeks ago, whom I crossposted here.

Whooee, 3.2v, I can see why things came to a halt. The dimms are ok but I could never get the cpu to work after that. I tried it in two other boards, including a new DFI M2RS. I didn't try a second cpu in the original M2R board, so it might have been ok.

Yes, I RMAed both cpu and board. Newegg didn't get back with me about what the defect might be.

So, sensors-configure is not necessary? I would really like to get lm-sensors working in Linux.

[justapost]

Whooee, 3.2v, I can see why things came to a halt. The dimms are ok but I could never get the cpu to work after that. I tried it in two other boards, including a new DFI M2RS. I didn't try a second cpu in the original M2R board, so it might have been ok.

Yes, I RMAed both cpu and board. Newegg didn't get back with me about what the defect might be.

So, sensors-configure is not necessary? I would really like to get lm-sensors working in Linux.

Hi vext,

I was wrong with the 3,2V the probing used random values so the applied value could have been anything up to 3.2V.
Jean from lm-sensors made a few patches in the last days so the next version 3.0.2 will run just fine on the Sapphire/DFI boards.
Everything lm-sensors dtects is the smbus controller (i2c-piix4) and the sensor-chip (it87). So if you add those modules manual you don't need to run sensors-detect.