RE: slow (s-l-o-w) install

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

 




----------------------------------------
> Date: Sat, 16 Feb 2008 15:31:45 -0600
> From: theatre@xxxxxxxxxxx
> To: fedora-list@xxxxxxxxxx
> Subject: Re: slow (s-l-o-w) install
> 
> On Sat, 16 Feb 2008 16:09:28 -0500
> Bill Davidsen  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
> 
> -- 
> fedora-list mailing list
> fedora-list@xxxxxxxxxx
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Well it makes sense and it doesn't at the same time. Does this affect the system once installed? Because it worked fine once installed for me anyway. Plus my laptop only has 2Gb of ram so where does that leave us? Will it affect those with less than 2Gb?

You won't have much luck with feedback to Intel through your service agent as they don't really give a shit dealer or not- I should know cause I'm supposedly an "intel partner" (mainly for market analysis purposes, I support AMD) and they have no feedback through this relationship. Your best bet is to email them yourself.
_________________________________________________________________
Overpaid or Underpaid? Check our comprehensive Salary Centre
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fcontent%2Emycareer%2Ecom%2Eau%2Fsalary%2Dcentre%3Fs%5Fcid%3D595810&_t=766724125&_r=Hotmail_Email_Tagline_MyCareer_Oct07&_m=EXT

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux