My VX800 bug of "boot linux with 2G mem >10 minutes" has been proved to be the problem of MTRR setting. Thanks for Carldani, Rudolf and Bari. 1 The root cause is: 1) The free memory I report to coreboot through ram_resource is [0, 1983M=2G-64M(Framebuffer)-1M(TOP 1M SM Memory)]. If I report [0, 1984M=2G-64M(Framebuffer)], then all is OK. 2) The src/cpu/x86/mtrr.c setting result of [0,1983M] is: reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1 reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1 reg02: base=0x60000000 (1536MB), size= 256MB: write-back, count=1 reg03: base=0x70000000 (1792MB), size= 128MB: write-back, count=1 reg04: base=0x78000000 (1920MB), size= 32MB: write-back, count=1 reg05: base=0x7a000000 (1952MB), size= 16MB: write-back, count=1 reg06: base=0x7b000000 (1968MB), size= 8MB: write-back, count=1 reg07: base=0x7b800000 (1976MB), size= 4MB: write-back, count=1 This setting make the last 3MB is uncached due to the lack of MTRR registers. And It seems that the last 3MB is frequently used by linux with kernel before(2.6.25.19), so the OS become slow. However XP and the linux with newest kernel (2.6.26.6-49.fc8) are not disturbed by the uncache of last 3MB.
The mtrr.c setting of [0,1984M] is: reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1 reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1 reg02: base=0x60000000 (1536MB), size= 256MB: write-back, count=1 reg03: base=0x70000000 (1792MB), size= 128MB: write-back, count=1 reg04: base=0x78000000 (1920MB), size= 64MB: write-back, count=1 all of memory area is cached, and all OS run at a good speed.
2 So we need improve mtrr.c to make it can treat with such input[0,1983M]. The legacybios handle my [0,1983] like this Cache [0,2048M] Unchace [1983M, 1984M] size=1M Uncache [1984M,2048M] size =64M. I guess the legacybios compare the number of '1' and '0' in 1983 to decide how to use minimum number of MTRR.
Carldaniel, you said on irc that mtrr.c also have the ability like legacybios(cache 2G,then uncache some area of 2G). But I didn't find any logic like that in mtrr.c.
3 And Stefan, your cx700 code will meet the same problem. Since the cx700's northbridge.c report the memory size in the same way of [0,xxxx-1M(TOP 1M SM Memory)]. The last 1M will also confuse the mtrr.c.
-jasonzhao
-----Original Message----- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006@gmx.net] Sent: Saturday, January 24, 2009 7:53 PM To: Jason Zhao Cc: r.marek@assembler.cz Subject: Re: [coreboot] Two test result(linux+2G-RAM>10minutes and install ubuntu8.10) of vx800 patch
Hi Jason,
thanks for the dumps.
On 24.01.2009 08:08, JasonZhao@viatech.com.cn wrote:
Carl and ruik: Here is some more result of acpidump, /proc/mtrr and /proc/meminfo. Some explanation of my memory using in coreboot: [topmem-64,tompmem] as framebuffer, [topmem-64M-64k,topmem-64M] as coreboot-table (In tables.c:rom_table_start = (*mem_top) - 64*1024;).
It is a bit strange that the DSDTs are identical for both memory configurations. The following parts of the code are suspicious:
Method (_CRS, 0, NotSerialized) { Name (BUF0, ResourceTemplate () {
[...] DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x80000000, // Range Minimum 0xBFFFFFFF, // Range Maximum 0x00000000, // Translation Offset 0x40000000, // Length ,, _Y00, AddressRangeMemory, TypeStatic) })
That address range is always the same, even if you only have 512M memory. Why? Will it cause problems if you have 3G memory?
And our MTRR setup is incomplete for the 2G case. The last 4 MB are uncached because we run out of MTRR registers. That will cause an extreme slowdown during boot.
I think the MTRR setup explains almost everything.
Regards, Carl-Daniel