• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Memtest86+ 4.20 ECC reporting

A

aamsel

Gawd
Joined
Jun 12, 2004
Messages
940
I am just testing some new server components, including a Supermicro X9SCL board, some Kingston Unbuffered ECC memory and a Xeon CPU, which together should fully support the ECC memory.

Running a boot disk of the current Memtest86+ 4.20 (and some old versions also), the screen reports ECC as OFF, and it can not be enabled.

The Supermicro BIOS shows the ECC memory, but I have no idea what to not trust:
the motherboard, or the test?

I am sure the Xeon is not to blame, and the memory would be very unlikely.

Please advise!

Thanks!!!
 
Experienced the same issue but with an asus board. Bios shows the memory as ECC enabled but memtest doesn't. Did you try setting the ecc option in memtest to enable(on)?
 
Yes, I toggled the ECC option to ON, but it still shows as OFF.
My understanding is that the "turning it on" in Memtest just enables
or disables logging of ECC errors, and does not actually turn on the
ECC itself. The ECC should be operational, but I would like to verify it.
This would not be the first time that I have purchased a setup that was
supposed to run ECC and did not, and I don't want to be fooled.

Anyone have any other knowledge of this?
 
I have the same with an asus P8B-X and a xeon E3-1230 with 8GB Crucial Unbuffered DDR3 1066 ECC ram.

BTW, What is this thread doing in the Data Storage forum?
 
Last edited:
I have accepted this as being normal.
The setup obviously supports ECC.

This started as a question related to setup of my
storage server. It is not fully a memory, CPU or Mobo
question, so if a mod feels this belongs elsewhere, please move
or delete it.
 
Thanks for the info. I just tried non-ECC ddr3 in the P8B-X and it will not even post with non-ECC so I believe ECC is working even though memtest86+4.20 says it is not.
 
From feedback/discussion at: http://www.newegg.com/Product/Product.aspx?Item=N82E16813131725 (Asus P8B WS, C206 board)

Pros: Nothing that outweighs the cons.

Cons: Asus advertises this as supporting ECC memory and so does Newegg, however the motherboard while being able to use ECC memory does not utilize any of the error correction functionality of ECC memory.

From dmidecode


Handle 0x0024, DMI type 16, 15 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 32 GB
Error Information Handle: No Error
Number Of Devices: 4

This is simply false advertising. Newegg needs to stop listening this as supporting ECC memory because it does *NOT*

Other Thoughts: Am never going to buy an ASUS again.
Click to expand...

and some other guy later responds to this with:

bob said:
Pros: It is a pleasure to deal with this nice mobo.

Cons: Absolutely nothing

Other Thoughts: As for ECC, the dmidecode output from a previous review is likely not relevant, since the memory controller is on the processor (and not on motherboard). Version 0704 of the BIOS has an option to enable/disable the ECC support.
Click to expand...

Could he be on to something?

I did however find this dmidecode output for an X9SCM-F motherboard (through some lucky googling): http://www.thomas-krenn.com/de/wiki/Hardwareinfos_mit_dmidecode_auslesen#Supermicro_X9SCM-F

Code: 
Handle 0x0027, DMI type 16, 23 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	[U][I]Error Correction Type: Single-bit ECC[/I][/U]
	Maximum Capacity: 32 GB
	Error Information Handle: No Error
	Number Of Devices: 4
 
Here is what I get for the ASUS P8B-X:

Code: 
Handle 0x0030, DMI type 16, 15 bytes
Physical Memory Array
        Location: System Board Or Motherboard
        Use: System Memory
        Error Correction Type: Multi-bit ECC
        Maximum Capacity: 32 GB
        Error Information Handle: No Error
        Number Of Devices: 4

I belive the BIOS is 0902 which I upgraded today from 0805.
 
So,
for C202 chipset (Asus P8B-X) it reports Multi-bit ECC
for C204 chipset (SM X9SCM-F) it reports Single-bit ECC
for C206 chipset (Asus P8B WS) it reports None

Interesting trend!
 
I just posted the following message in the ASUS forums regarding P8B-WS ECC:

I followed essentially the same path. Disabled or "Auto" is not terribly reassuring. Memtest86++ doesn't add any confidence, nor did the response from Asus tech support. I'm not a happy camper ...

So ... Here's the plan. I pulled out the Intel Xeon E3-1200 data sheet (volume 2). PCI device zero has lots of CPU configuration data. Use "lspci -s 0:0.0 -xxxx". From the data sheet (Table 2-7), offset 0x48-0x4F specifies MCHBAR ... in my case, the value was 0xFED10001 (YMMV). (The trailing one indicates that mapping is enabled).

Since "dd if=/dev/mem" would not cooperate, you write a short program using mmap on /dev/mem to access the MCHBAR area and write it (32KB) to a file. Then examine hexdump of that file. As per tables 2.16.2 and 2.16.3 from the data sheet, we examine offsets 0x5004 and 0x5008 in the hexdump. In my case, both values were: "10 10 66 03". All of the bit fields seem reasonable. In particular, the "03" is specified as "ECC active in both I/O and ECC logic" !

Now, I have not read the entire data sheet, and there could be more to it ... but it looks to me like the Sandy Bridge Xeons perform ECC operations in the processor itself, and the above referenced bits SEEM to be turning on this capability.

My GUESS is that memtest86++ has not yet been updated to support Sandy Bridge Xeons. Lots of time/anguish wasted on this issue ... guess that's why they call it the bleeding edge. Hopefully I can save someone else some trouble ... enjoy ..
Click to expand...
 
jvsfms said:
I just posted the following message in the ASUS forums regarding P8B-WS ECC:
Click to expand...

Thank you so much! I was just about to make my own thread about help on deciding mobo for my build, and the asus p8b ws was only an alternative, but now it's a solid winner in my eyes, and I can finally finalize my build!

What you found seems to be on par with what one of the guys on newegg said, but didn't supply proof of.

Any chance you could give us a direct link to your post on the asus forums?
 
meatincereal said:
If you have non-ECC memory available, could you perhaps try those in the board and compare results?
Click to expand...

Sorry for the delay in responding. These systems have been "buttoned up" and burned-in for several days, and also I don't have any NON-ECC memory handy ... so I'm not likely to be able to perform the tests you requested.

However, my GUESS is that there wouldn't be any difference. I suspect that the motherboard turns on the Flag in the processor whenever the motherboard is configured for AUTO. The processor then sends out the extra ECC bits, whether there is real memory there or not. When it reads it back, unless it identifies a correctable error (which probably never happens without the ECC bits populated)
it only sets some error flags which are ignored.

This is all mere speculation on my part. I don't know if any operating systems have been modified to actually accumulate error correction information from the processor itself .... This issue probably won't be fully settled until Memtest86 is updated and the Operating Systems are modified to support ECC error tracking and reporting.

It would be nice if the motherboards made some kind of attempt to determine whether or not the ECC is physically present ... if nothing else, just to add piece of mind ...

Sorry ...
 
Additional messages have been posted to the thread on the ASUS forum. It seems pretty clear that the P8B WS BIOS needs to be modified to include ECC information in the DMI data that is presented to the Operating System. My -guess- is that it IS performing correction, but needs to communicate the ECC configuration via the DMI data so that the Operating Systems (and possible memtest86) can proceed appropriately.
 
You must log in or register to reply here.
Back
Top