Ivy Bridge Core i3s and ECC - Santa Clara, we have a problem...

[pschatz100]

I'm running a Core i3-3240 on a Supermicro X9SCM-F motherboard. I have ECC memory installed. Are you saying that the ECC feature is not being used? Seems weird to me.

At the time I bought the processor, Intel documentation said that it supports ECC.

 

[hervon]

I'm running a Core i3 3240 on a Supermicro X9SCM-F motherboard (Sandy bridge.) I have ECC memory installed. Are you saying that the ECC feature is not being used? Seems weird to me.

At the time I bought the processor, Intel documentation said that it supports ECC.

I suggest you try the simple program for your benefit and others with similar systems.

 

[Ericloewe]

I suggest you try the simple program for your benefit and others with similar systems.

This.

Intel has backtracked on the statement that Ivy Bridge i3s support ECC, so please tell us what results you get from the little program. I know it's a pain to reboot into a live CD/USB and do this, but these are unusual circumstances.

 

[Bidule0hm]

I just checked and gcc is installed by default in the jails, so if you already have one or prefer to create one instead of rebooting I think it's a good solution ;)

 

[alexg]

TS140. Intel(R) Core(TM) i3-4130 CPU using intel1155_ecc_check2.c program

Code:

5004-5007h: 20 0 63 3
5008-500Bh: 10 0 61 3

Interpretation:
------------------
Channel 0:
  DIMM A&B swapped: 1
  DIMM A Size:      8192 MB
  DIMM B Size:      0 MB
  DIMM A dual rank: 1
  DIMM B dual rank: 0
  DIMM A DDR width: 8
  DIMM B DDR width: 8
  Rank Interleave:  1
  Enh. Interleave:  1
  ECC in IO:        1
  ECC in Logic:     1
Channel 1:
  DIMM A&B swapped: 1
  DIMM A Size:      4096 MB
  DIMM B Size:      0 MB
  DIMM A dual rank: 0
  DIMM B dual rank: 0
  DIMM A DDR width: 8
  DIMM B DDR width: 8
  Rank Interleave:  1
  Enh. Interleave:  1
  ECC in IO:        1
  ECC in Logic:     1

 

[Ericloewe]

I just checked and gcc is installed by default in the jails, so if you already have one or prefer to create one instead of rebooting I think it's a good solution ;)

If the jail is working properly, that program has no business returning anything meaningful. 9.2.1.5 or older did include gcc in the main install, so they're also an option.

 

[Bidule0hm]

The idea is to compile it in the jail but to use it in the main install. But I haven't read the source code so maybe that doesn't work too. It's just an option to those who want to investigate further... ;)

 

[Ericloewe]

The idea is to compile it in the jail but to use it in the main install. But I haven't read the source code so maybe that doesn't work too. It's just an option to those who want to investigate further... ;)

That might work.

 

[pschatz100]

I'm running a core i3-3240 cpu on a Supermicro X9SCM-F motherboard. It looks like I'm OK.
My output was:
5004-5007h: 10 0 63 3
5008-500Bh: 10 0 63 3

Further down the referenced thread in the HardOCP forum, there is a quote:
"According to motherboard manufacturer Supermicro, if a Core i3 processor is used with a server chipset platform such as Intel 3400/3420/3450, the CPU will support ECC with UDIMM.[24] When asked, Intel confirmed that, although the Intel 5 series chipset supports non-ECC memory only with the Core i5 or i3 processors, using those processors on a motherboard with 3400 series chipsets it will support the ECC function of ECC memory."

So it would appear that core i3 processors support ECC memory with certain chipsets only. Actually, this is what I expected, but it would be useful to know more about which chipsets work OK and which do not.

Comments for folks not familiar with programming...
I created an Ubuntu live image following Ericloewe's instructions in the first post, then compiled and ran the ecc_check program. There are a few additional details to be aware of:
1) After booting into the Ubuntu Live environment, copy the extracted files for ecc_check into one of the directories under "Home." I used "Downloads". Do not compile them on the second USB stick.
2) Start a Terminal session, cd to the appropriate directory then run the gcc command. To execute the program after compiling, run "sudo ./ecc_check".

 

[cyberjock]

Well I'll be... I always had a hunch that the i3s were out of place with their ECC support.

And I'll save you guys the trouble of using the liveCD. Use the attached file in FreeNAS...

# python ecc_check.py

Keep in mind that this is *only* supposed to work for Sandy Bridge and Ivy Bridge CPUs. AFAIK there is no reasonable test for ECC RAM If it works on anything else, that's strictly a coincidence and you should *not* take the results of the bits in those memory locations as being validation. The *whole* problem with proving ECC works is that it is damn close to impossible to prove that your hardware truly and unequivocally supports (and is using) ECC properly.

I'm betting it's about to get very bloody for a bunch of people...

Before the very detailed thread that me and a few other heavy hitters in the forum had the discussion on ECC last year, I thought that the only way to have ECC functioning was:

1. Server chipset
2. Xeon CPU only
3. ECC RAM

Having ECC with i3s was really hard to truly believe for me, as was the Pentiums. I could *maybe* buy Pentiums because they are so low on the product line compared to Xeon, but i3s are somewhat formidable for many tasks, and Intel definitely takes great effort to ensure that the Xeon line remains profitable and that other products don't cannibalize from that product line.
Of course, the ARK clearly documented differently and it's a bit difficult to contradict Intel on their own documentation. Intel doesn't even make it particularly easy (if there is such a thing as "easy" for Intel) to figure out what hardware supports what except to buy their top-of-the-line products (which many people here prefer to save money where they can).

If I could rub my crystal ball I'm somewhat expecting the following:

-All i3s do not and never have used ECC (whoops!)
-Pentiums probably don't use ECC either
- Celerons, even those claiming to support ECC, probably don't do ECC.

So what does this mean? "If you want ECC to function properly you have to buy ECC RAM, the supported server chipset, and a Xeon CPU."

I'm truly hoping that for the sake of all the users out there we're going to find out that when all is said and done that i3s and Pentiums do support ECC. But that's not looking too likely right now. Especially considering that Intel has already fixed their ARKs to ECC support = no.

 

[Bidule0hm]

"it is damn close to impossible to prove that your hardware truly and unequivocally supports (and is using) ECC properly." in fact there is something relatively easy we can do to check but it's definitely not for the noobs (even if easy for the non-noobs): insert some very thin plastic isolator between a data pin of a DIMM stick and the DIMM socket. This bit will then always generate an error so if ECC works we should see the errors in the IPMI log, and if it don't works, well, no errors in the log and the system will probably panic/reboot/halt/whatever.

If you try this don't use your real FreeNAS install and your real data disks of course, and don't blame me if something goes wrong, it's your choice to do it or not.

I really want to try this because I want a clear and definitive answer: yes or no. but right now it's not the best time to do this for me so it'll wait until I can.

 

[Ericloewe]

Well I'll be... I always had a hunch that the i3s were out of place with their ECC support.

And I'll save you guys the trouble of using the liveCD. Use the attached file in FreeNAS...

# python ecc_check.py

Keep in mind that this is *only* supposed to work for Sandy Bridge and Ivy Bridge CPUs. AFAIK there is no reasonable test for ECC RAM If it works on anything else, that's strictly a coincidence and you should *not* take the results of the bits in those memory locations as being validation. The *whole* problem with proving ECC works is that it is damn close to impossible to prove that your hardware truly and unequivocally supports (and is using) ECC properly.

I'm betting it's about to get very bloody for a bunch of people...

Before the very detailed thread that me and a few other heavy hitters in the forum had the discussion on ECC last year, I thought that the only way to have ECC functioning was:

1. Server chipset
2. Xeon CPU only
3. ECC RAM

Having ECC with i3s was really hard to truly believe for me, as was the Pentiums. I could *maybe* buy Pentiums because they are so low on the product line compared to Xeon, but i3s are somewhat formidable for many tasks, and Intel definitely takes great effort to ensure that the Xeon line remains profitable and that other products don't cannibalize from that product line.
Of course, the ARK clearly documented differently and it's a bit difficult to contradict Intel on their own documentation. Intel doesn't even make it particularly easy (if there is such a thing as "easy" for Intel) to figure out what hardware supports what except to buy their top-of-the-line products (which many people here prefer to save money where they can).

If I could rub my crystal ball I'm somewhat expecting the following:

-All i3s do not and never have used ECC (whoops!)
-Pentiums probably don't use ECC either
- Celerons, even those claiming to support ECC, probably don't do ECC.

So what does this mean? "If you want ECC to function properly you have to buy ECC RAM, the supported server chipset, and a Xeon CPU."

I'm truly hoping that for the sake of all the users out there we're going to find out that when all is said and done that i3s and Pentiums do support ECC. But that's not looking too likely right now. Especially considering that Intel has already fixed their ARKs to ECC support = no.

The output is coherent on Haswell, so I'm inclined to consider it valid until a more detailed reading of the Haswell datasheet.

This will only be truly settled if someone manages to write a program that sets Haswell's ECC error injection registers. Or if someone tries a more... mechanical solution...

What makes no sense is that there's evidence (see pschatz's post above) that Ivy Bridge i3s do support ECC, according to the processor itself, contrary to what Intel is now saying.

 

[cyberjock]

"it is damn close to impossible to prove that your hardware truly and unequivocally supports (and is using) ECC properly." in fact there is something relatively easy we can do to check but it's definitely not for the noobs (even if easy for the non-noobs): insert some very thin plastic isolator between a data pin of a DIMM stick and the DIMM socket. This bit will then always generate an error so if ECC works we should see the errors in the IPMI log, and if it don't works, well, no errors in the log and the system will probably panic/reboot/halt/whatever.

If you try this don't use your real FreeNAS install and your real data disks of course, and don't blame me if something goes wrong, it's your choice to do it or not.

I really want to try this because I want a clear and definitive answer: yes or no. but right now it's not the best time to do this for me so it'll wait until I can.

Ok, so which pin on DDR3 needs to not function? I have a spare DIMM I can try for this... I'll use an exacto knife to cut that path. ;)

But on-topic, who out there is really going to buy RAM just to deliberately break it just to prove that their build uses ECC properly?

 

[Bidule0hm]

http://buffalo.jp/products/b-solutions/oem/pdf/60026902-01.pdf

Page 2: how the pins are numbered.
Page 3: pinout. Any pin labeled DQx with x = 0-63 should do the trick. I recommend one of the first pins to don't bother too much with the counting, pin 3 or 4 (DQ0 or 1), or pin 9 or 10 (DQ2 or 3) should be perfect ;)

"who out there is really going to buy RAM just to deliberately break it" Actually I suggested a non-destructive method (if done correctly), but yeah, it's not for everyone :)

 

[cyberjock]

I tried to use plastic once.. the tolerances in the slot were too close and I could never get it to work. :(

 

[Bidule0hm]

Oh ok. I was also thinking about some varnish easily cleanable with some solvent (but the risk is that if the varnish isn't resistant enough it doesn't isolate the pin).

Which CPU(s)/MB(s) you want to test with the bad stick?

 

[cyberjock]

I have some old board with an x58 chipset and a Xeon and my X9SCM-F. :)

 

[DrKK]

G3220 with ECC RAM on an X10SLM:

Code:

[root@giskard] /tmp# python ecccheck.py
5004-5007h: 10 10 60 3
5008-500Bh: 10 10 60 3
[root@giskard] /tmp#

Is this good or bad?

 

[Ericloewe]

G3220 with ECC RAM on an X10SLM:

Code:

[root@giskard] /tmp# python ecccheck.py
5004-5007h: 10 10 60 3
5008-500Bh: 10 10 60 3
[root@giskard] /tmp#

Is this good or bad?

It's good, probably. 3 means ECC fully enabled. First line is channel A, second one is channel B.

 

[jw123]

I get:

Code:

5004-5007h: 20 0 63 3
5008-500Bh: 20 0 63 3 

With the following hardware:
i3-4130T
Intel S1200V3RPL
2*8GB Crucial 1600MHz Unbuffered ECC DDR3

Given this is a Haswell, I'm not sure how useful the results are.