lkml.org 
[lkml]   [2005]   [Feb]   [22]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateTue, 22 Feb 2005 11:14:30 +0100
FromMartin MOKREJŠ <>
SubjectRe: memory management weirdness
Ingo Molnar wrote:
> * Andi Kleen <ak@muc.de> wrote:
> 
> 
>>>  Although I've not re-tested this today again, it used to help a bit to specify
>>>mem=3548M to decrease memory used by linux (tested with AGP card plugged in, when
>>>bios reported 3556MB RAM only).
>>>
>>>  I found that removing the AGP based videoc card and using an old PCI based
>>>video card results in bios detecting 4072MB of RAM. But still, the machine was
>>>slow. I've tried to "cat >| /proc/mtrr" to alter the memory settings, but the
>>>result was only a partial speedup.
>>>
>>>  I'm not sure how to convince linux kernel to run fast again.
>>
>>It's most likely a MTRR problem. Play more with them.
> 
> 
> in particular, try to create two small tables in the same format: one
> showing the e820 memory map as reported in your kernel log, and one
> showing the mtrr areas. If there is any e820 area that is not write-back
> cached via the mtrr mappings then that's the problem. You can also use
> "mem=exactmap,..." to fix up the memory map that the BIOS provides to
> Linux. Slowdowns are very often such MTRR problems. (perhaps the kernel
> should report RAM areas that are not covered by MTRR write-back?)

I've just extracted the requested info from the files I've put on web.
Here it is:

                                               2.4.30-pre1-bk5    2.6.11-rc4-bk7
0000000000000000 - 000000000009fc00 (usable)       +                    +
000000000009fc00 - 00000000000a0000 (reserved)     +                    +
00000000000e8000 - 0000000000100000 (reserved)     +                    +
0000000000100000 - 00000000de330000 (usable)       +                    +
00000000de330000 - 00000000de340000 (ACPI data)    +                    +
00000000de340000 - 00000000de3f0000 (ACPI NVS)     +                    +
00000000de3f0000 - 00000000de400000 (reserved)     +                    +
00000000ffb80000 - 0000000100000000 (reserved)     +                    +
found SMP MP-table at 000ff780                     +                    +
hm, page 000ff000 reserved twice.                  +                    - ???
hm, page 00100000 reserved twice.                  +                    - ???
hm, page 000f1000 reserved twice.                  +                    - ???
hm, page 000f2000 reserved twice.                  +                    - ???



                                                                    2.4.30-pre1-bk5    2.6.11-rc4-bk7
reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1       +                      +
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1       +                      +
reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1       +                      +
reg03: base=0xd0000000 (3328MB), size= 128MB: write-back, count=1       +                      +
reg04: base=0xd8000000 (3456MB), size=  64MB: write-back, count=1       +                      +
reg05: base=0xdc000000 (3520MB), size=  32MB: write-back, count=1       +                      +
reg06: base=0xfe800000 (4072MB), size=   4MB: write-combining, count=1  +                      - !!!
reg06: base=0xf0000000 (3840MB), size= 128MB: write-combining, count=1  +                      +
The 4MB area should be AGP aperture, as it was set in BIOS to 4MB only
The files on web contain concatened infor from dmes, iomem, interrupts, mtrr, lspci:
http://www.natur.cuni.cz/~mmokrejs/tmp/4MB/2.4.30-pre1-bk5
http://www.natur.cuni.cz/~mmokrejs/tmp/4MB/2.6.11-rc4-bk7


So, 2.6 kernel does not see AGP aperture area. What to do next? ;)
Martin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:10    [from the cache]
©2003-2008