Re: Intel's response Linux/MTRR/8GB Memory Support / Why doesn'tthe kernel realize the BIOS has problems and re-map appropriately?
From: Justin Piszcz
Date: Fri Jun 01 2007 - 15:19:24 EST
It works ok on
my machine (correctly detects the condition, adjusts end_pfn, and keeps
the machine fast), aside from the fact that X won't start.
But X won't start? :\
On Fri, 1 Jun 2007, Jesse Barnes wrote:
and the MTRRs (from /proc/mtrr, from private email):
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=0xcf800000 (3320MB), size= 8MB: uncachable, count=1
reg04: base=0xcf700000 (3319MB), size= 1MB: uncachable, count=1
reg05: base=0x100000000 (4096MB), size=4096MB: write-back, count=1
reg06: base=0x200000000 (8192MB), size= 512MB: write-back, count=1
reg07: base=0x220000000 (8704MB), size= 128MB: write-back, count=1
so the ranges mapped as cacheable are:
0-3319MB
4096-8832MB
leaving 64MB of memory at the top of RAM uncached. What do you want to
bet that something important (kernel code?) is getting loaded there..
So essentially it's a BIOS problem, it's not setting up the MTRRs
properly in order to map all of RAM as cacheable. As Andi says, complain
to Intel.
If it's just 64M you'll end up losing, you could try the "[RFC] trim memory
not covered by MTRR WB type" patch I posted yesterday. It won't reinit the
MTRRs (maybe we should) but it will at least prevent your system from
crawling if the BIOS doesn't set them up right. That would at least let you
use most of your memory until the BIOS guys acknowledge that they have a
problem (or we get proper PAT support, which I think would make this problem
go away as well).
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/