Re: HIGHMEM64G Kernel (2.6.23.1) makes system crawl

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Rajkumar S wrote:
On 10/24/07, Robert Hancock <[email protected]> wrote:
Rajkumar S wrote:
Hello,

I am using a Core 2 Duo E6750 CPU on an intel DG33FB mother board with
4GB Ram, running Debian Lenny.

Since the box has 4 GB ram I compiled a big mem kernel, but the
machine is very slow while running big mem kernel. It takes about 37
minutes to compile the intel e1000 driver  (e1000-7.6.5.tar.gz) from
intel site. But it's performing normally when using a non big mem
kernel. The diff of the .config between working and non working is as
follows.
Post your contents of /proc/mtrr. Likely a BIOS bug which has been seen
on a number of Intel boards, which doesn't mark all of RAM as cachable.

I have upgraded the bios to latest  (v. 0293 October 02, 2007)
Previously the /proc/mtrr was:

ravanan:~# cat /proc/mtrr
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=0xcf600000 (3318MB), size=   2MB: uncachable, count=1
reg05: base=0xcf500000 (3317MB), size=   1MB: uncachable, count=1
reg06: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg07: base=0x120000000 (4608MB), size= 128MB: write-back, count=1

Now after upgrading the bios it's

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=0xcf400000 (3316MB), size=   4MB: uncachable, count=1
reg05: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg06: base=0x120000000 (4608MB), size= 128MB: write-back, count=1

Yup, it's a BIOS bug. Your BIOS only marks ram up to physical address of 4736MB as cacheable, while the actual RAM reported by the BIOS goes up to physical address 4800MB.

I think we had a patch in -mm to detect this case and disable the extra memory (64MB in this case) to keep the kernel from using it.

--
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/

-
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/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux