User Tip: Mac Pro and Error Correcting Code RAM Memory

Last modified: Aug 13, 2017 7:14 PM
19 7761 Last modified Aug 13, 2017 7:14 PM

The Mac Pro silver towers and dark cylinder (and likely the upcoming iMac Pro) all with Xeon processor, feature 72-bits wide Error Correction Code (ECC) Memory. Eight additional check bits are stored with each 64-bit wide word.


The check bits are a specific set of permutations and combinations of parity across different subsets of bits in the word. These patterns have been carefully chosen so that, if a single-bit error occurs, the single bit that went bad is identified and corrected by Hardware, in one stretched memory cycle.


An error bit is also set, and a background process will eventually see that an error occurred and will tabulate the errors, by memory module. You can read out those tables with Apple System Profiler.

 menu > About this Mac > (System Report) > Memory ...

... and see which modules are accumulating errors. Those modules are BAD.


User uploaded file

graphic from Anandtech.com


One good approach to finding the offending modules is to run that report from time to time as you work normally, and you may catch the offending module(s). The report data are STATIC -- you must refresh or re-invoke the report to get new data.


Running Rember in the background will cause additional reads and writes in the less used sections of RAM, but Rember does not know about Error Correction, so it will never report any errors.


Uncorrectable errors, such as most double-bit errors, cause your Mac to halt to keep RAM errors from poisoning your data. It generates a distinctive kernel panic, machine check, with multiple reporting banks and/or detected by multiple processors. The essential parts of the panic report are saved in NVRAM, and your Mac will attempt to post it as a panic log at the next Restart.


So memory problems do not fester undetected on these Macs -- RAM memory works perfectly until the machine halts with an uncorrectable error.


The error correction hardware is used very aggressively at Startup. ANY error, correctible or not cause the associated slots to be declared "empty" and they will not be used by MacOS. These modules are BAD. But on subsequent startups, they will be tested again and may then be used by the system. This does not change the fact that such modules are BAD. Those modules found BAD at startup will be shown as slots "empty" in the same report I cited above.

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.