[coreboot] K8 machine with (a lot of) ram from 2 vendors keeps resetting
Ward Vandewege
ward at gnu.org
Wed Sep 2 23:14:57 CEST 2009
Hi all,
I'm having some problems with a supermicro h8dme board with 2 K8 processors
and 64 GB of ram.
Sadly, the ram is of two types (that was not my decision :/). We have 8x 4GB
Samsung M393T5160QZA-CE6 and 8x 4GB Kingston KVR667D2D4P5/4G. Both of these
types of ram are dual rank DDR2, 667 MHz, CL5, 1.8 V, registered, ECC.
The memory is installed like this:
BANK CPU1 CPU2
1B KING KING
1A KING KING
2B KING KING
2A KING KING
3B SAMS SAMS
3A SAMS SAMS
4B SAMS SAMS
4A SAMS SAMS
With the proprietary BIOS, this setup works perfectly. That said, the manual
for the board does say it's not recommended to mix memory types. Our system
integrator mentions that when 16 banks are used, the memory runs at maximum
533MHz.
I should mention that this particular coreboot port has one oddity - the
memory on each CPU must be matched because we don't know how to do the SPD
address switch to detect ram on the second CPU.
As you can see in the diagram above, that condition is met.
There are two problems. First, with the above (64GB) configuration coreboot
just keeps resetting itself after printing "Clearing initial memory region:".
I've attached a log with RAM_TIMING_DEBUG enabled, see
minicom-20090902-with-64G.cap.
Perhaps this is related to coreboot not dropping down to 533MHz with 16 DIMMs
installed?
Dropping the installed ram down to 48GB like this:
BANK CPU1 CPU2
1B KING KING
1A KING KING
2B KING KING
2A KING KING
3B SAMS SAMS
3A SAMS SAMS
4B -- --
4A -- --
Makes the boot get all the way to seabios, but the board still resets itself
just before booting the linux kernel. See attached
minicom-20090902-with-48G.cap.
Any thoughts on what might be happening here, or how I could debug further?
Thanks,
Ward.
--
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minicom-20090902-with-64G.cap
Type: application/cap
Size: 50637 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090902/ff6b9d35/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minicom-20090902-with-48G.cap
Type: application/cap
Size: 404768 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090902/ff6b9d35/attachment-0001.bin>
More information about the coreboot
mailing list