slow (s-l-o-w) install

Frank Cox theatre at sasktel.net
Sat Feb 16 21:31:45 UTC 2008


On Sat, 16 Feb 2008 16:09:28 -0500
Bill Davidsen <davidsen at tmr.com> wrote:

> It's a known limitation of some BIOS versions. I suspect it would happen 
> with that other O/S as well, actually.

After doing some Google-research, I think I have a bit of an understanding of
this issue.  Someone who knows more about this, please correct me where my
understanding is wrong.

Here is the contents of /proc/mtrr on the computer in question:

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
reg07: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1

Now, it's my understanding that somehow, there is 64mb of ram that is not
properly accounted for in the above report, and that is what causes the problem
because this 64mb of ram is right at the top of the memory and the kernel
attempts to install itself at the top of the memory.  This has the effect of
dragging everything that interacts with the kernel (meaning everything, period)
down to a snail's pace.

(If someone could explain the meaning of the /proc/mtrr report, and how that
64mb problem is derived from it I would appreciate it -- I've been looking it
over and don't understand this part of it at all.)

The reason for this problem is that the bios is not correctly reporting or
accounting for the state of the last 64mb of ram in the computer.

Obviously, the best fix for this would be to get a bios that works properly in
this regard.  However, would there be a second-best fix where one could
possibly tell the kernel to ignore that last 64mb of ram and use everything
else instead?  As this seems to be a problem in the very latest crop of Intel
motherboards, it will likely come up quite a bit over the next while as these
boards become more common in the market.

Is there a way, perhaps, to draw this issue to Intel's attention and get it
fixed properly in the bios?  I'm thinking I will bring it up up to the dealer
that I purchased this computer from -- he is an authorized Intel dealer and
perhaps will have some sort of a way to get some input back to Intel.  Before I
do this, is my understanding of the problem correct and is there any other
information that should also be included here?


-- 
MELVILLE THEATRE ~ Melville Sask ~ http://www.melvilletheatre.com




More information about the users mailing list