Hyper + Asus x58 issue

[ground]

Hello, 

I recently wanted to finally properly test my 2000c7 Hypers and decided to try run them on my trusted R3E with W3680. But one of the sticks refused posting - first thought was obviously shelf death or transport damage. With cleaned contacts exact same issue. Swapped to R3F with different CPU - still unchanged. Moved to x58a-oc - suddenly stick works perfectly fine. Compared SPD with the stick thats working correctly, no differences. Just for fun decided to dig out the DOA stick of 1866c7 I got in a recent purchase - and off course, runs 32M as as it should on its own as well as with other sticks, even at >1000mhz 6-7-5-20. 

Tried both sticks - on their own and with other sticks - on asus again, and no luck getting them to detect, always no completable post.

Now finally went and grabbed P5Q3 deluxe just to see if the issue is asus x58 or asus in general, and on there both weird sticks run flawlessly. 

Beyond flashing a completely different SPD and different bios versions (which I doubt given the issue shows with 2 different boards) I’m out of ideas. Has anyone had this before and got any ideas how to go about fixing it?

-Ground

[TerraRaptor]

What about jedec ram in chA and problematic hypers in chB/chC?

[ground]

37 minutes ago, TerraRaptor said:

What about jedec ram in chA and problematic hypers in chB/chC?

just tried this. 

With normal sticks, the board boots straight up. With these, it loops training 3-5 times but completes post. In bios, all 3x2 gb get detected (or 2x2 if only testing with 1 of the problematic sticks). Once xp is booted, cpu-tweaker detects triple channel yet only shows channel A. Win 7 64 bit bluescreens a couple seconds after loading desktop, with both configurations. OS works normal with only the jedec stick. I have not yet tested performance in XP (and won’t be able to today sadly) but I am not sure what to expect. 

[ground]

Disabling memory recheck with a working stick+damaged stick results in the same behavior as with the jedec stick; windows 7 still bluescreens on asus x58 with the problematic sticks. 

[ground]

While I figured out how to get the sticks “running” again, I’m anything but satisfied with the solution I found. 

I noticed while experimenting with the damaged 1866c7 that it wouldn’t reliably run windows 7. @Digg_desuggested it might be accessible memory related - so I reduced the available memory on the sticks via a modded spd to 1GB per stick (512mbit with DR - not losing any efficiency in the process). Suddenly they booted windows 7 without issue, and even work again on the R3E (R3F not tested yet but I’d bet it works there too). HOWEVER, it appears that I now need a bit more voltage to stabilise the sticks as before, maybe losing 15-20MHz at CL6 with same volts. Not the solution I was searching but better than a dead stick at least. 

I’ve yet to test mixed density for efficiency, I hope I do not have to flash all my sticks

[ludek]

That's interesting! When I was OCing a mobile Socket P, playing around with SPD was the only way to achieve better result. But that is pain if there are completely no OC options in BIOS. This makes OC harder, but also more fun. Sometimes I had to desolder SPD chips (in DDR2 it's I2C memory for example 24C02) and reflash them. It's good to have hot air station, a programmer and soldering station. Keep pushing

One question, do you use SPD Tool? Or it's something more sophisticated piece of software?

// EDIT:

Always do a backup of your SPD! It's worth your while.

Edited March 20, 2021 by ludek

[ground]

1 hour ago, ludek said:

One question, do you use SPD Tool? Or it's something more sophisticated piece of software?

I just use RWEverything since it is all you need to modify for lower density is Byte 4 and Byte 5 with ddr3 and its the simplest to use (in my opinion) for basic spd mods like that. 

SPD Backup is obviously the first thing to do once you modify sticks like this!

SPD mods are underappreciated sometimes