RE: [suse-amd64] PCI memory hole and remapping (was -> Re: [suse-amd64] Memory Problem: 3Gb instead of 4Gb, TYAN K8WE s2895, 2x252 Opteron )
Ok, so I tried to play around with that a little bit. With memory remapping, /proc/mtrr looks like that:
reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 reg01: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 reg02: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 reg03: base=0xe0000000 (3584MB), size= 128MB: write-combining, count=1
This doesn't work. If your BIOS is doing this (as opposed to you mucking with the settings), I need to get the AMD BIOS developers to talk to your BIOS developers. You can not overlap *anything* with uncacheable and get anything but uncacheable back. Uncacheable trumps all other MTRR settings. See p 229 of http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/ 24593.pdf You may want to check if your BIOS has an option for "Discrete" or "continuous" usage of MTRRs. Experiment with both settings - I believe "discrete" should work better in a memory hoisting environmnet. -Mark Langsdorf AMD, Inc.
Finally our system shows 4GB of RAM !! Dual Opteron 250 4GB of RAM Tyan 2895 with two 16x PCI-express slots Bios v1.01 Suse9.3: kernel 2.6.11.4-21.7-smp BIOS settings: Main > Installed OS > Linux Advanced > Hammer Config > MTRR Mapping Discrete Advanced > Hammer Config > Memory Hole > Memhole Mapping > Software Advanced > Hammer Config > Memory Hole > IOMMU > Enabled Hope this help someone... ...Luc... Luc Renambot luc@evl.uic.edu Electronic Visualization Lab (M/ C 152) EVL Phone (312) 996-3002 University of Illinois at Chicago EVL FAX (312) 413-7585 851 S. Morgan St. Room 1120 SEO http://www.evl.uic.edu/luc Chicago, IL 60607-7053 On Jul 14, 2005, at 11:48 AM, Langsdorf, Mark wrote:
Ok, so I tried to play around with that a little bit. With memory remapping, /proc/mtrr looks like that:
reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 reg01: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 reg02: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 reg03: base=0xe0000000 (3584MB), size= 128MB: write-combining, count=1
This doesn't work. If your BIOS is doing this (as opposed to you mucking with the settings), I need to get the AMD BIOS developers to talk to your BIOS developers.
You can not overlap *anything* with uncacheable and get anything but uncacheable back. Uncacheable trumps all other MTRR settings. See p 229 of http://www.amd.com/us-en/assets/content_type/ white_papers_and_tech_docs/ 24593.pdf
You may want to check if your BIOS has an option for "Discrete" or "continuous" usage of MTRRs. Experiment with both settings - I believe "discrete" should work better in a memory hoisting environmnet.
-Mark Langsdorf AMD, Inc.
-- Check the List-Unsubscribe header to unsubscribe For additional commands, email: suse-amd64-help@suse.com
Langsdorf, Mark wrote
Ok, so I tried to play around with that a little bit. With memory remapping, /proc/mtrr looks like that: reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 reg01: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 reg02: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 reg03: base=0xe0000000 (3584MB), size= 128MB: write-combining, count=1
This doesn't work.
Yes, that's what I thought when reading all the info here. So I guess that's the reason why so many things go wrong when activating memory remapping in the bios (like tg3 failing etc.).
If your BIOS is doing this (as opposed to you mucking with the settings), I need to get the AMD BIOS developers to talk to your BIOS developers.
That would be great. Please do that. What's shown above is indeed the mtrr settings that come from the bios. I didn't change anything. And that's the same on two different PCs (both iwth A8V), so it's not that just one PC is broken or sth... However, whatever problems I was reporting to ASUS, I never got anything helpful back, or a fix in the next release etc. They seem to ignore user bug reports, but I guess they won't ignore AMD...
You can not overlap *anything* with uncacheable and get anything but uncacheable back. Uncacheable trumps all other MTRR settings. See p 229 of http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/ 24593.pdf
Ok, so this really should be a bios bug.
You may want to check if your BIOS has an option for "Discrete" or "continuous" usage of MTRRs. Experiment with both settings - I believe "discrete" should work better in a memory hoisting environmnet.
Unfortunately not! I read about other mainboards having this option in the bios and looked for it carefully, because other people reported they could fix the problem with the fglrx driver using this setting. Unfortunately, Asus didn't put such a setting in their latest release... cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
participants (3)
-
Frank Steiner -
Langsdorf, Mark -
Luc Renambot