Cold Boot? Memory Died? [email protected] = who you need to contact

[red930]

OzSnoal,

 

Simply put, if the BIOS does not require the data outside of byte 63 why do you?

 

Once again, are you asking for something from DFI that no other manufacturer delivers?

 

Are you asking for a rewrite of the JDEC standards?

 

Regarding the spurious SPD data.

 

If you have the same stick of RAM giving you two different sets of data when moved between slots, check the program first. If two different programs resolve the same BAD data, change the RAM. If two different sticks of RAM with two different programs resolve the same BAD data, change the motherboard.

[unreal]

Awards Angry_games the longest post award

 

And I thought mine was long

 

Nice post, just wondering if you read what I said..

 

Do you think I should RMA the board because it is clearly the board thats causing these issues as everything else has been ruled out...

[Angry_Games]

sure you can RMA the board...but in my opinion, as long as you are using anything that is based on UTT (Untested, never forget that), you will probably continue to see problems.

 

but go ahead and RMA to eliminate the board from the equation.

[unreal]

OzSnoal,

 

Simply put, if the BIOS does not require the data outside of byte 63 why do you?

 

Once again, are you asking for something from DFI that no other manufacturer delivers?

 

Are you asking for a rewrite of the JDEC standards?

 

Regarding the spurious SPD data.

 

If you have the same stick of RAM giving you two different sets of data when moved between slots, check the program first. If two different programs resolve the same BAD data, change the RAM. If two different sticks of RAM with two different programs resolve the same BAD data, change the motherboard.

 

What program other than CPU-z reads the codes?

 

Sisandra? :confused:

[OzSnoal]

ExRoadie.

 

The spurious SPD data is the exact reason for my post in the first place.

 

My whole reason for investigating how SPD is read is because of problems reading it, both in the above case and other cases where 'half' the amount of RAM is returned.

 

I wanted to check the SPD spec. to confirm that the serial data was 'checksummed', it was. Whether this is performed in the BIOS code, I don't know. All my post is about, is to give the BIOS writers/those investigating the problem a point of view they may/(may not) have though of. If I had the bios code, I would'nt have posted because I could read it and satisfied my curiousity, but I don't so I throw things in the air.

 

Nothing I have written goes against the jedec specification.

 

What am I asking DFI todo? They may already have implemented it in the way I described or in a better way. Or if the checksum is not being checked it should be.

 

Forget about what area the BIOS reads or does not. Let's talk only about a serial EEPROM. A serial EEPROM, when reading from a specific address should consistently return the same data from that address, all the time, no matter which slot. You do bring up a good point about using another program to determine if it returns the same data.

 

The only program I know that reads the SPD area is cpu-z.

[red930]

You should be more precise about your intent since you are posting in a DFI forum thread that you basically started. If you think about the situation you might see that some of this should be discussed in an Off Topic thread just to put some distance between the two issues.

 

Everest Home and Right Mark Memory Analyzer are other very reliable programs that can read both the SPD and actual settings in the BIOS.

 

Right Mark Memory Analyzer is my favorite for getting every last bit of detail. The interface is hard to use but if you take the time to learn it you will be rewarded.

 

You have to select the module index to read the proper RAM slot for SPD info but it not only provides the whole number setting but also the speed.

 

RMMA download link...

http://www.softpedia.com/get/System/Benchm...-Analyzer.shtml

 

Everest Home download link...

http://www.lavalys.com/products/download.php?pid=1&lang=en

[AndyOCZ]

sure you can RMA the board...but in my opinion, as long as you are using anything that is based on UTT (Untested, never forget that), you will probably continue to see problems.

 

but go ahead and RMA to eliminate the board from the equation.

 

Let us not forget that there is no such thing as "untested" memory.

 

This is what OCZ does:

 

1) All chips are TESTED on a "million dollar" machine that speed grades and tests chip integrity. Crap is thrown out. Good stuff is kept.

 

2) Modules are assembled, then TESTED. Hmmmm

 

3) Modules are again TESTED and speed graded.

 

4) Modules are TESTED again in dual channel at rated speeds.

 

 

Now let me see:

 

Chips are not tested at the factory.

 

Chips are tested at least 4 times before they are sold.

 

That makes them no longer untested.

 

Now, I'm not arguing with AG. This was just to clarify testing. Your board might be just like all other boards and your memory could very well be the problem. If it is RMA the memory.

 

Thanks

[unreal]

sure you can RMA the board...but in my opinion, as long as you are using anything that is based on UTT (Untested, never forget that), you will probably continue to see problems.

 

but go ahead and RMA to eliminate the board from the equation.

 

OK I shall pull the PC2700 out of the other pc and test that, then RMA if it stilll happens.

[OzSnoal]

Thanks Exroadie, Great program that, RMMA

 

You can save the SPD area exactly as it is stored in the serial flash chip. Nice.

And I noticed that 00 00 is stored as the Manufacture date in my VX, which means year 20'00', week '00'.

[MaKo]

Let us not forget that there is no such thing as "untested" memory.

Yeah, that was my thought also. The UTT label is somewhat of a misnomer when you think about what OCZ, Mushkin, and the like do to these babies before they are put up for sale.

[crazykooter]

Just to add to this if I may. There is something silly go wrong with these boards. I have 2 sets of tcdd which now require 2.9 volts just to boot stock speeds. even with relaxed timings. My utt fails to boot all now. Neither stick will even post. I was able to post with them with a bios reset and what not. I checked the vdimm and on failed post and it was at 2.56 now if I powered down the system the vdimm was zero but as soon as I threw the power switch the voltage went to 2.77. Why is it dropping .2 volts on boot ? This is getting rather frustrating now since I have almost no more ram. I am worried my tccd will require more volts and then burn. Plus to top off the tccd issue I was able to do 290 fsb 1:1 @ 2.9v when I got them and now I am maxed at 255fsb 1:1 and I can no longer use divider for some reason. It will not boot to windows not matter what voltage a select. This is with my 2 week old DFI ultra D. My other 2 month old Ultra D is worse then this one. Not sure what to do at this point.

[AndyOCZ]

Glad to hear your little mate Chico is OK, much more important than computers in my opinion, ( hope I don't get shot on here for saying that)

You do a fine job on here for us I've read many of your posts and they've been very helpfull.

 

Thanks!

 

It makes you think twice when even a dog takes ill. We have to pay attention to other aspects of our lives as well as our computers.

 

It's always a pleasure to help when I can.