X48 Rampage Formula Preview.

[mikeyakame]

Gah. I've now got an official reason to complain to Asus to fix something on the RF.

S3 Suspend to Ram is f****d. it inversed my Dram Fine Clock Delay values. By inverse I mean original value XOR'd with F. So original was 3h.

Fh ^ 3h = Ch = 13T

Had to full power cycle it to clear the values back to original 3T. Windows wouldn't even shutdown, I'm lucky it didn't corrupt the registry or anything at all.

This is something that's completely intolerable. It's upto bios code to correctly save PCI registers for suspend so this is Asus' problem not Windows. I'll be writing an angry tech support email when I wake up tomorrow explaining how they need to fix this and they are lucky it didn't cost me any data. I'll make a complaint about lack of NB/CPU clock skews while I am doing it.

Do any of you guys have problems with Dram Clock Fine Delay values after suspend resume? I could tell I did straight away because the LCD poster backlight stays on permanently which means to me memory clock skews are way way way too tight.

Edit:

No sooner did I say everything was ok, did I find a problem.
Running SFC /scannow to find and fix whatever the hell Asus' broken suspend corrupted. Guess I won't be using it again, funny thing is I never use it either and figured I'd try it to see if it actually works.

Edit2:

Definitely Asus fault. This is from Windows Event Viewer.

The platform firmware has corrupted memory across the previous system power transition. Please check for updated firmware for your system.

Edit3:

Meh, Thank god for Windows 7 having automatic system restore points being saved. Fixed corrupted NTDLL.dll library that was broken by screwed up S3 suspend.
I think I might know what the culprit is too. I have a hunch it's tREF, Self Refresh Interval. At 3120T it's dangerously low and It wouldn't surprise me if this corrupted memory. Damn Asus and not even bothering to include code to self track the value according to DRAM frequency.

I don't really want to break my system again trying to fix it but I'll give it a shot, and see if it helps any by forcefully setting it through MCHBAR PCI register and trying to S3 suspend again and see if it corrupts or not.

Bah It's not even saving the PCI registers correctly, what a joke. Let me explain bold underlined registers too.

Before suspend.
FED14260 0B373D91 130E0078 CFD19500 0302BF33 <- CHA
FED14660 0B373D91 130E0078 CFD19500 0302BF33 <- CHB

Highlighted is tREF = D195h - C000h. = 1195h = 4501T
Which i set myself through writing the MCHBAR register for CHA/CHB for 577MHz (DDR2-1154)

After suspend.
FED14260 0B373D91 130E0078 CFCC3000 0302BF33 <- CHA
FED14660 0B373D91 130E0078 CFCC3000 0302BF33 <- CHB

Highlighted is tREF = CC30h - C000h. = C30h = 3120T
Not correctly saved during suspend, reverted back to Intel default value for 400MHz (DDR2-800).

Before Suspend
FED14510 00008523 00000CF7 00000425 00000012 <-CHA
FED14910 00008323 0000020B 0000084E 00000052 <-CHB

After Suspend
FED14510 0000853D 00000CF7 00000425 00000023 <- CHA
FED14910 0000833D 0000020B 0000084E 00000043 <- CHB


These ones are the kickers though and the huge problem. Compare 23h, 12h for CHA and 23h, 52h for CHB to below after suspend values of 3Dh, 23h for CHA. 3Dh, 43h for CHB.
Now you wonder what these are. Let me explain and so you know these correlate with Dimm 1-4 Fine clock delay in Everest.

The Last values of 23h, 43h CHA. 12h, 52h CHB are some other kind of skew most likely DQS. Data Strobe Skew. They change too before and after.

23h != 3Dh.
Before
2h = CHA2 Dimm Clock Fine Delay = 2T
3h = CHA1 Dimm Clock Fine Delay = 3T

After
3h = CHA2 Dimm Clock Fine Delay = 3T
Dh = CHA1 Dimm Clock Fine Delay = 14T

Same goes for CHB

23h != 3Dh.

Before
2h = CHB2 Dimm Clock Fine Delay = 2T
3h = CHB1 Dimm Clock Fine Delay = 3T

After
3h = CHB2 Dimm Clock Fine Delay = 3T
Dh = CHB1 Dimm Clock Fine Delay = 14T

Now 1T = ~50ps according to how Asus bios for DRAM clock skew sets these up.
So my point is on CHA1/CHB1 the DRAM Clock Skew values are being delayed an extra 550PS or a bit less and this is corrupt your OS in 2 minutes or less territory and should never EVER happen, EVER. A2/B2 by 50ps but they aren't occupied.

Edit5: UPDATE

Heres a couple more but I don't know exactly what they are as they are unknowns but I know they are static values.

Before Suspend
FED145D0 80000008 11330002 00F1CCCC 38004CD0 <- CHA
FED149D0 80000008 11330002 00F1CCCC 38004CD0 <- CHB

After Suspend
FED145D0 80000008 11330002 00F1CCCC 38000C90 <- CHA
FED149D0 80000008 11330002 00F1CCCC 38000C90 <- CHB

All I know is they are something to do with MCH internal timings or skews, but no doubt they are probably important. CHA and CHB settings are always 400h offset apart They seem to exist between 200h-5FFh for CHA, 600h - 9FFh for CHB. Outside this are other values unknown.

I made this neat so I don't have to explain it twice in an email.