Is anyone using this configuration? does it work reliably? I am asking as I don't know if this has been fixed yet.
For a real server platform this is a must have, the ram issues are the one valid point that leah made...
- Thanks in advance for any replies
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/27/2017 03:27 PM, Taiidan@gmx.com wrote:
Is anyone using this configuration? does it work reliably? I am asking as I don't know if this has been fixed yet.
For a real server platform this is a must have, the ram issues are the one valid point that leah made...
- Thanks in advance for any replies
We use such a machine here in production, with the caveat that an older coreboot revision is used. That being said, keep the four slots closest to CPU1 unpopulated (i.e. fill all 8 slots on CPU0, and the 4 farthest from CPU1) and you should have no problems reaching 192GB. Those particular slots appear to have physical routing layer issues caused by marginal design, and thus far we have had no reason to even attempt a workaround given the high cost involved.
As always, if someone else would like to try to work around the corruption issues, they are more than welcome. Populating all four slots closest to CPU1 with large ECC registered DIMMs is a surefire way to recreate the instability -- note a training failure is not common, the main issue is that the marginal routing causes severe memory corruption when the BKDG-recommended algorithms are used.
- -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com
Timothy Pearson wrote:
Populating all four slots closest to CPU1 with large ECC registered DIMMs is a surefire way to recreate the instability -- note a training failure is not common, the main issue is that the marginal routing causes severe memory corruption when the BKDG-recommended algorithms are used.
What does the vendor BIOS do?
//Peter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/29/2017 09:38 AM, Peter Stuge wrote:
Timothy Pearson wrote:
Populating all four slots closest to CPU1 with large ECC registered DIMMs is a surefire way to recreate the instability -- note a training failure is not common, the main issue is that the marginal routing causes severe memory corruption when the BKDG-recommended algorithms are used.
What does the vendor BIOS do?
Unknown. I would imagine there is a hack in the vendor BIOS to work around this board-specific issue, but that doesn't help coreboot very much. We had looked into it before, but decided it was not worth the cost to research and implement a fix.
For what it's worth, there are several threads online about the KGPE-D16 and memory corruption with the vendor BIOS. It seems to have taken ASUS some time to iterate and work around the problem.
- -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com
-
Peter Stuge -
Taiidan＠gmx.com -
Timothy Pearson