BUILD Small form factor home NAS build, hardware feedback and some questions

[Dusan]

No, FreeNAS doesn't ship with a C compiler. I installed FreeBSD 9.1 in a VM to compile it.

 

[Krutet]

The tool posted on this thread is what I plan to use to check. I actually already ordered the g2020, and I plan to keep it to try just in case. If both don't work, I guess I'll send them back and try something else.

I would love to hear if the mobo worked with the g2020 because then I can use my old g2020 for my new s1200kpr which I just ordered..!?

 

[iostream]

I'll let you know if I try it. I'll try the g860 and if that one works, I won't try the g2020, since I'll just be returning it. The new processor comes in tomorrow, so it's looking like a weekend build.

 

[cyberjock]

I would love to hear if the mobo worked with the g2020 because then I can use my old g2020 for my new s1200kbr which I just ordered..!?

I'm sure the g2020 will work. Plenty of people use that CPU. The g860 and if it works is what interests me. That's a big questionmark in my book.

Edit: Doh, wrong thread. Yeah, the g2020 would be interesting too...

 

[Krutet]

I'm sure the g2020 will work. Plenty of people use that CPU. The g860 and if it works is what interests me. That's a big questionmark in my book.

Edit: Doh, wrong thread. Yeah, the g2020 would be interesting too...

The thing is that the g2020 is not listed in the compatibility list on the page of the s1200kpr but a lot of "similar" processors are listed. Whats you experience with these kind of things? Can it work anyway? Does it mere mean that its not tested but could work? I don't mean just ECC but will it work at all?

http://ark.intel.com/products/67346/

 

[cyberjock]

I really don't know. I try to stick to the stuff that is actually listed as compatible, but there have been plenty of cases of stuff working despite not being on the compatibility list. Generally for important stuff like servers I don't try to "wing it" and save a buck by buying stuff that isn't necessarily compatible. You don't want to think everything is fine and then a few months later find out there's some fatal flaw and your data has been lost.

If it were a standard desktop I'd just make sure that its well documented that a given component really does work. And I'd be scared of a BIOS update making my CPU suddenly not work. :P

 

[Krutet]

I really don't know. I try to stick to the stuff that is actually listed as compatible, but there have been plenty of cases of stuff working despite not being on the compatibility list. Generally for important stuff like servers I don't try to "wing it" and save a buck by buying stuff that isn't necessarily compatible. You don't want to think everything is fine and then a few months later find out there's some fatal flaw and your data has been lost.

If it were a standard desktop I'd just make sure that its well documented that a given component really does work. And I'd be scared of a BIOS update making my CPU suddenly not work. :P

That's true. Normally I wouldn't do it but now I already have the CPU from another project.. I'll try it out when my ram arrives and update this post.

Edit: for fellow surfers looking for an answer I can confirm that the g2020 runs on the s1200kpr but I don't know if ecc works or not because there is no way to test that.

 

[iostream]

Another small update. I have the build almost completed. The M1015 has been successfully cross flashed, motherboard, CPU and RAM all installed. I haven't installed the disks yet, I'll do that tomorrow. I booted from the FreeNAS 9.1.1 image, everything looks pretty good. Opened up a shell and ran the command Dusan suggested, check the output:

[root@freenas ~]# dmidecode -t 16
# dmidecode 2.11
SMBIOS 2.7 present.

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

It looks like that command at least thinks ECC is being utilized. Once I get the disks installed, I plan to install a jail with a compiler and compile and run that C program. Or, I might port the program to python and make it more useful to anybody running vanilla FreeNAS who doesn't want to install a jail and compiler just to run that one program.
Thanks everyone for your help and suggestions. More info to come.
Steve

 

[cyberjock]

If you port the program to python I know I'd use it. :)

Might be interesting to see who is and isn't using ECC but think that they are. After all, ECC is pretty critical for good ZFS reliability.

 

[iostream]

Well, I was going to wait until tomorrow to do this, but when I get an itch, I have to scratch it. :-D I successfully ported the ecc_check C program to python, and it works perfectly. Here's what it gives me on my FreeNAS system:

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

The last byte can be decoded as such (according to this thread)

According to Intel's datasheet:
0: ECC disabled
1: ECC is active in I/O; ECC logic is not active In this case.
2: ECC is disabled in I/O, but ECC logic is enabled.
3: ECC active in both I/O and ECC logic

So it seems I am running with ECC.

You can grab the python code here: http://pastebin.com/sxd7QcYj

If somebody doesn't beat me to it, I'll make another thread dedicated to the python version of this code tomorrow, so it's not buried here.

Now off to bed for me.

Thanks,
Steve

 

[cyberjock]

Outstanding.

Mine is weird..

5004-5007h: ff ff ff ff
5008-500Bh: ff ff ff ff

Maybe because I'm running it in a VM?

 

[Dusan]

You will get FFs in a VM. It doesn't make sense to emulate ECC inside a VM. When the host system is using it, then all VMs are "protected".

It's interesting that iostream's system reports Multi-bit ECC, while my X9SCL+E3-1230v2 SMBIOS reports only Single-bit ECC.
On second thought, that may be just broken Supermicro BIOS. When you check memory modules via dmidecode -t 17, you will usually see this for ECC modules:

Code:

        Total Width: 72 bits
        Data Width: 64 bits

which means 64 data bits + 8 bits for ECC. However, my Supermicro reports:

Code:

        Total Width: 128 bits
        Data Width: 64 bits

Which is definitely not the reality :), as the spec sheet for my memory states: KVR1333D3E9SK2/8G is a kit of two 512M x 72-bit (4GB) DDR3-1333 CL9 SDRAM (Synchronous DRAM), 2Rx8 ECC memory modules.

 

[cyberjock]

But you need to keep in mind a few things. To actually use the ECC bits your RAM, motherboard, and CPU must all agree to use ECC. If any one of them don't then you don't really have ECC protection. In many cases, you can actually install ECC RAM and it will work just fine as non-ECC RAM.

And now you know why I was so enthusiastic to try your python conversion. Many people refuse to buy the server grade stuff(to save money, reuse old hardware, etc.) and I'm sure many of them bought ECC RAM and aren't actually using the ECC bits. It's not as simple as dropping in ECC RAM and you now have ECC support. A trustworthy script to prove you are or aren't using ECC could be very important(and would be very crucial to using ZFS).

 

[Dusan]

cyberjock, be careful calling this script trustworthy and recommending it to other people. The script/code is based on information from Intel Xeon E3-1200v2 datasheet (see http://hardforum.com/showpost.php?p=1037860125&postcount=10 and http://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200v2-vol-2-datasheet.html, chapter 2.16).
Will it work properly on Xeon E3v2s? Definitely.
Will it work properly on other Ivy Bridge CPUs? Very probably yes.
Will it work properly on other Intel CPUs? Maybe yes.
Will it work properly on AMD CPUs? Who knows!

So, until somebody does the research and shows that the MCHBAR Memory Controller registers are at the same address, with the same meaning also in other CPU microarchitectures, I would not trust the output of the script on anything else than E3v1/2 Xeons and maybe other Sandy/Ivy Bridge CPUs (and maybe Haswell). (Sandy/Ivy Bridge does the ECC "magic" in the processor, but other architectures may do it in the chipset...)

 

[Dusan]

Being curious I checked the Intel Atom S1200 datasheet (http://www.intel.com/content/dam/ww...eets/atom-processor-s1200-datasheet-vol-2.pdf).
Intel Atom S1200 supports ECC, but the datasheet doesn't mention any MCHBAR registers. It seems you need to check the DECCCT register instead (see table 4-26 in the datasheet I linked above & also try to search for MCHBAR -- you won't find it there). So, the script will definitely not work properly on Intel Atoms.

 

[cyberjock]

Yeah, I wasn't expecting full compatibility. I was more curious as to how the VM would handle it. I have all ECC compatible components and I have no doubt that I'm using my ECC mode. Just reading up on how all this stuff works.

 

[Dusan]

The sad truth is that there seems to be no CPU-architecture independent way to detect that ECC is enabled and works. Many people use Memtest86(+), but it only works after Memtest was updated to support the respective CPU family/architecture. In theory SMBIOS should report it via DMI in structure types 16/17/(18), but I already saw my share of funny DMI data. :(

 

[survive]

Hi guys,

Just posting my results from iostream's script.

Using the system in my sig (Supermicro X9SCL-F with an i3-2100) I get a "3", so it confirms that these boards do support ECC when paired with a Sandy Bridge i3 chip.

-Will

 

[cyberjock]

How did you come to the conclusion that a 3 meant the same 3 as in the xeons? I think that's where the discussion is. There's no real guarantee that a 3 with a Xeon means ecc is working while on non xeons it means something else. Perhaps not related to the ecc function at all.

 

[Dusan]

Exactly. i3-2100 is a Sandy Bridge CPU, the same microarchitecture as the E3 v1 Xeons.
However, while the data sheet for Sandy Bridge E3 Xeons (http://www.intel.com/content/dam/ww...heets/xeon-e3-1200-family-vol-2-datasheet.pdf), table 2.16.2 (page 219) says that bits 24:25 of the MAD_DIMM_ch0 register signalize "ECC is active in the channel (ECC)" and "11 = ECC active in both I/O and ECC logic",
the data sheet for Sandy Bridge Desktop CPUs (such as i3-2100, http://www.intel.com/content/dam/ww...eets/2nd-gen-core-desktop-vol-2-datasheet.pdf), table 2.16.2 (page 215) says that bits 24:25 of the MAD_DIMM_ch0 register are "Reserved".