And verily, didst Kevin_Gassiot@veritasdgc.com announce to the hordes:
--=_alternative 001262FC86256E2A_= MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1
I am running an S2885 board with 8 GB of memory, and the system sees the whole lot, and I am able to load a 7.9 GB volume into a visualization app with no problems. I have a BIOS version 101k, loaded the update 193 kernel to day, along with the 5332 AMD64 driver from Nvidia, and haven't seen any problems yet.
Did you mean 101k then, or 101i? Cos there's no such thing as 101k on tyan's site at the moment. (Unless I'm hitting a proxy cache that's not being updated)
This combination seems to have fixed a whole raft of problems that I was seeing. Before the mtrr patch (which looks like it is included in the 193 update source code), I would start swapping as soon as the buffer cache filled up, instead of reclaiming space from buffer cache. It also cleared up problems with memory mapping that was causing the nvidia driver to hang on a system with large memory. In addition, I no longer see any mention of APIC version errors in boot.log.
I have enabled ECC, and haven't seen any stability issues yet, but I am only using PC2700 memory. One of our system builders told me that they have seen a lot of problems with 400 MHz memory, even on what is supposedly certified to work. Something to do with the signal, and the length of the connections to the DIMM slots being on the ragged edge of what is possible (I amnot an EE, so don't have a clue if this is valid or not )
I take it this is where RAM in one slot configuration will work, while the same DIMMs in a different slot order won't, is it?
Kevin Gassiot Advanced Systems Group Visualization Systems Support
Veritas DGC 10300 Town Park Dr. Houston, Texas 77072 832-351-8978 kevin=5Fgassiot@veritasdgc.com
-----"Eugene de Villiers" <edevilliers@hotmail.com> wrote: -----
To: suse-amd64@suse.com From: "Eugene de Villiers" <edevilliers@hotmail.com> Date: 01/28/2004 05:59PM Subject: [suse-amd64] missing memory
Hi all
I am almost certain this is not a Suse issue, but I thought I might inquire= =20 just in case.
As stated before, I have a Tyan K8W motherboard with 4Gb of DDR400 memory=20 running Suse 9.0 AMD64 with the patch kernel.
The BIOS registers 4Gb of memory, but the operating system only shows ~2.5 =
Gb of addressable memory (and starts swopping when it hits this limit). Any= =20 clue what is causing this?
Since the Opteron memory controller is integral to the CPU, is this a=20 fundamental problem with 244s or could it still be in the BIOS?
Additionally, if I enable ECC in the BIOS I encounter unpredictable=20 failures. How can this be? I thought Opterons ONLY work with registered ECC= =20 memory. Could BIOS settings be incompattible with the memory controller?
Has anybody with a K8W updated to the 2885101i BIOS beta revision? Does it =
do any of the things it purports to fix: * Add DDR400 display support. * Add AMD Errata 86 fix * Open HT frequency options * Update CPU module to fix the CPU APIC Version error * Replace IORR with MTRR for AGP Aperture memory * Update Silicon Image Option ROM to version 5.0.31 (from tyan )
Thanks for your patience!
Eugene
PS. Thanks also to previous correspondents regarding the ATI driver issue=20 (it doesnt yet exist for 64bit linux)
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Need info in a hurry? Use MSN Search! http://search.msn.co.za/
--=20 Check the List-Unsubscribe header to unsubscribe For additional commands, email: suse-amd64-help@suse.com --=_alternative 001262FC86256E2A_=--