> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
