mrcWritelevellingError on boot, Supermicro X11 board

[voleking]

Hi, first post here! I'm in the process building a system for a freeNAS setup using an X11SSM-F with an i3-6320 & 16Gb ECC RAM. However, on boot I'm getting an odd error that googling hasn't turned up any results for. I get a '0x08 mrcwritelevelingerror' message and then ram error code beeps and the boot stalls - no other info, unfortunately. Now, I'm assuming of course that my RAM is shonky, or just incompatible (it's a 2 stick Samsung 16Gb 2133 kit, M391A1G43EB1-CPBQ). As well as putting in a query with Supermicro, I figured I'd ask here as there's a lot of experience with X11 boards- I don't want to splurge on another set of RAM only to find it's a board or processor fault! Has anyone here come across a the same error? I did try a board search but 'write' and 'levelling' are too common terms to narrow it down.

(edit: the RAM is on the qvl)

Cheers,

Simon

 

[headhunterU23]

Hi,

I have the same problem with a Supermicro X11SSL-F and 4x 8GB ECC Kingston KVR24E17S8/8MA. Do you have the error message with the board empty? Or do you already have a PCI-E storage controller installed? I have no problems with the motherboard and RAM combination, the system POST fine. The "0x08=mrcWriteLevelingError" appears when I add an Intel P3520 PCI-E ssd OR a LSI SAS2008 9211-8i. I have issues with both these PCI-E cards on multiple systems (MSI Z170a Gaming Pro Carbon & Supermicro H8SCM-F). On the X11SSL-F I receive the aforementioned message but with the other boards the system simply refuses to POST (black screen & blinking LEDs). I doubt the devices are faulty because they run just fine on a Z370-G (ran the tests that Intel asked).

I contacted Intel and MSI about these issues but I fear the problem has more to do with a memory controller compatibility issue among different chipsets and not just a specific combination of hardware. As you can see on this webpage https://www.hardwareluxx.de/communi...er-performance-kompatibilitaet-1181270-2.html the problem occurs with other SSDs as well. It doesn't seem like a manufacturer specific issue but rather with a global memory controller issue that have problems with very different products. After 2 months of emails with different manufacturers they pretty much all gave up because their devices seem to work perfectly fine on some systems and they consider this problem as an isolated problem that occurs only on our systems. As they suspect faulty hardware other than theirs they quickly try to close the ticket. But there's definitely a memory controller compatibility issue with multiple different chipsets and devices. I'm waiting for MSI to reply on Wednesday but I'm pretty sure they'll tell me that my problem is device specific and that they won't release a BIOS for a problem that is none of their concern.

For one moment I thought the problem might be BIOS related but I tried all versions from release to the latest with the same results.

The X11SSL-F is a brand new MB/CPU combination with the latest BIOS version. I'm about to contact Supermicro but this problem seems more related with memory controller issues completely manufacturer independent rather than a problem with Supermicro. Could you send me your Supermicro ticket ID so that I can add it in my own ticket? The reason I ask you that is because I have the feeling that if we contact them one by one with our own specific configurations they will take this as a vendor specific problem. They'll tell you to run some tests, try different RAM modules, tell you everything is fine with their board and close your case considering you're a noob not knowing how to choose your hardware and skip the fact that it happens with perfectly fine hardware that seems to have issues only in some situations. I have the same issue with 3 different systems that have nothing in common (SM H8SCM-F is a 2012 MB, MSI Z170a Gaming Pro Carbon is a 2016 MB and the X11SSL-F is as 2017 MB) in terms of RAM, chipset and CPU, it cannot just be faulty hardware, there's something else.

Cheers,

Headhunter

 

[voleking]

Hi headhunter, in my case the board was empty- I had no other storage controllers installed. After doing more digging the only other info I've found was actually your post on the hardwareluxx forum. In my case it turned out to be a dodgy CPU (an i3-6320- I'm not sure if it can't handle ECC due to an issue with the IMC, if it is just busted, or if it just doesn't like this particular board (I've just today got my hands on a regular lga1151 board to test it with, which will at least tell me if the CPU is working with non-ECC ram).

Did you hear anything useful from MSI?

 

[headhunterU23]

Hi headhunter, in my case the board was empty- I had no other storage controllers installed. After doing more digging the only other info I've found was actually your post on the hardwareluxx forum. In my case it turned out to be a dodgy CPU (an i3-6320- I'm not sure if it can't handle ECC due to an issue with the IMC, if it is just busted, or if it just doesn't like this particular board (I've just today got my hands on a regular lga1151 board to test it with, which will at least tell me if the CPU is working with non-ECC ram).

Did you hear anything useful from MSI?

Nope not a word from them for the last 10 days, I was expecting this tbh. I managed to make the LSI SAS2008 9211-8i (DELL PERC H310) to work on the MSI board and the H8SCM-F with all RAM detected by trying the "tape trick" as explained in that post https://forums.unraid.net/topic/27724-solved-perc-h310-causing-system-not-to-boot/ .

The trick was to put electrical tape on B5 + B6 on the PCI-E connector of the HBA and the system POST just fine. Now I need to find the diagram of this HBA to know what these pins are used for so that I can try the same trick with the Intel P3520.

I hope you managed to determine if your CPU was good for the trash bin, from what you wrote on your initial post your CPU IMC should work just fine with DDR4 2133 as stated on this site https://en.wikichip.org/wiki/intel/core_i3/i3-6320 but I have doubts about your RAM compatibility even if on paper it should work just fine. Personally I rarely tried using tested memory from Supermicro website because you can't find the anywhere, I always trusted Kingston and never had a RAM module that is listed on Kingston's website as compatible not working with a Supermicro board. If you can, go ask your retailer if he has a Kingston RAM module like the KVR24E17D8/16 and if he's ready to test it on your X11SSM-F with your i3 onboard.

 

[voleking]

Hi, yeah the CPU was toast it turns out, didn't work at all in the other board (threw out CPU not detected beep code). The fact the Supermicro board actually booted and threw a memory error was a kinda misleading.The good news is the Samsung ram is working fine now on the X11SSM-F with a G3900 and everything seems OK.

I'd also be interested to know what that tape trick is fixing. Possibly our two different faults give the same error due to both being a PCIE problem, mine due to a CPU fault of some sort and yours due to this weird connector bug? Glad the tape trick as fixed at least one of your cards so far anyway.

 

[headhunterU23]

These pins are for the SMBus: B5 (SMCLK, SMBus clock) an B6 (SMDAT, SMBus data). Still the same shit: PCI-E devices conflicting with RAM modules probably. As there doesn't seem to be a jumper for disabling the SMBus on the MSI Z170 I guess I'll keep the tape trick as a working solution (H8SCM-F and X11SSx boards do have this jumper though). I'm going to try that on the H8SCM-F, this board would do a great FreeNAS host with its 32GB ECC RAM and an Opteron 6 cores and I'll sell the Z170 or repurpose it as a second gaming station.

 

[headhunterU23]

Yeah, that was the SMBus on the H8SCM-F, opened both jumpers (JI2C1/JI2C2) and it POST. Damn, third system this year that drives me crazy for weeks and I never think at disabling the SMBus. P3520 and the whole 32GB of RAM are showing up, time to remove the electrical tape on the DELL PERC H310. Well I guess the Z170 will return to its initial purpose of being a gaming card.