memory hole (was Re: Tyan Thunder K8W S2885 with 4GB memory missing memory??)
After reading this and the other related thread
http://lists.debian.org/debian-amd64/2005/09/msg00738.html .
I experimented with some bios settings on my system
(http://lists.debian.org/debian-amd64/2005/09/msg00757.html) , which may
be of interest to others puzzling about this.
1) With software memory hole mapping and continuous MTRR:
Scanning NUMA topology in Northbridge 24
Number of nodes 2 (30010)
Node 0 MemBase 0000000000000000 Limit 000000013fffffff
Node 1 MemBase 0000000140000000 Limit 000000023fffffff
node 1 shift 24 addr 140000000 conflict 0
node 1 shift 25 addr 1fe000000 conflict 0
Using node hash shift of 26
Bootmem setup node 0 0000000000000000-000000013fffffff
Bootmem setup node 1 0000000140000000-000000023fffffff
No mptable found.
On node 0 totalpages: 1310719
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 1306623 pages, LIFO batch:16
HighMem zone: 0 pages, LIFO batch:1
On node 1 totalpages: 1048575
DMA zone: 0 pages, LIFO batch:1
Normal zone: 1048575 pages, LIFO batch:16
HighMem zone: 0 pages, LIFO batch:1
/proc/mtrr:
reg00: base=0x00000000 ( 0MB), size=8192MB: write-back, count=1
reg01: base=0x200000000 (8192MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
free total: 8160856 kB
2) With hardware memory hole mapping and continiuous MTRR:
Scanning NUMA topology in Northbridge 24
Number of nodes 2 (30010)
Node 0 MemBase 0000000000000000 Limit 0000000103ffffff
Node 1 MemBase 0000000104000000 Limit 0000000203ffffff
node 1 shift 24 addr 104000000 conflict 0
node 1 shift 25 addr 1fe000000 conflict 0
Using node hash shift of 26
Bootmem setup node 0 0000000000000000-0000000103ffffff
Bootmem setup node 1 0000000104000000-0000000203ffffff
No mptable found.
On node 0 totalpages: 1064959
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 1060863 pages, LIFO batch:16
HighMem zone: 0 pages, LIFO batch:1
On node 1 totalpages: 1048575
DMA zone: 0 pages, LIFO batch:1
Normal zone: 1048575 pages, LIFO batch:16
HighMem zone: 0 pages, LIFO batch:1
/proc/mtrr:
reg00: base=0x00000000 ( 0MB), size=8192MB: write-back, count=1
reg01: base=0x200000000 (8192MB), size= 64MB: write-back, count=1
reg02: base=0xfc000000 (4032MB), size= 64MB: uncachable, count=1
free total: 8174328 kB (13.5MB more than above)
3) With hardware memory hole mapping and discrete MTRR:
Northbridge memory is the same as above.
/proc/mtrr:
reg00: base=0x100000000 (4096MB), size=4096MB: write-back, count=1
reg01: base=0x200000000 (8192MB), size= 64MB: write-back, count=1
reg02: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg03: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg04: base=0xc0000000 (3072MB), size= 512MB: write-back, count=1
reg05: base=0xe0000000 (3584MB), size= 256MB: write-back, count=1
reg06: base=0xfd7e0000 (4055MB), size= 64KB: write-combining, count=1
reg07: base=0xfd7c0000 (4055MB), size= 128KB: write-combining, count=1
the last 2 are set up by X, with a kernel error message of "no more
MTRRs available". But X seems to make do with what it can get.
free total: 7977720 kB (196.6 MB less than 2)
Dont know what it all means for memory access, or X performance. Keeping
the third set up for now.
Elaine
On Wed, 2005-09-28 at 10:37 +0200, Lionel Elie Mamane wrote:
> On Wed, Sep 28, 2005 at 02:58:41AM +0200, Lionel Elie Mamane wrote:
>
> > On my S2895, I have in Advanced / Hammer / Memory Hole / Memhole
> > mapping, the choice between disabled, software and hardware. The one
> > that works is software. If I set hardware, it just goes back to
> > disabled after boot.
>
> There is an informative thread on this on
> http://lists.suse.com/archive/suse-amd64/2005-Jul/0064.html .
>
> In particular,
> http://lists.suse.com/archive/suse-amd64/2005-Jul/0110.html
> says you need a revision E or later CPU to do hardware remapping :-(
> Had I known, I'd have payed more attention to which CPU to buy.
>
> --
> Lionel
>
>
--
Reply to: