learnings from upgrading a notebook

Wed Sep 3 13:20:11 UTC 2008

On Tue, Sep 02, 2008 at 07:33:08PM -0400, D. Hugh Redelmeier wrote:
> Why do you say that?  The Intel and AMD manuals make overlapping MTRR
> values well-defined (with certain constraints on types).

Yes, but that still doesn't make it possible to set write-combining.
The fact the overlap is well defined clearly makes it not possible to do
what you really want to do, which is to use write combining for your
video card, hence what the BIOS is doing is stupid because it makes it
impossible to do what the user wants to do, and hence the BIOS is wrong.
Now perhaps for some setups with a lot of ram there isn't much choice.
It is either some ram is uncached (which is awful) or you can't write
combine on the video card (which is bad but not awful).

> "Not nice" I would certainly agree with.  These vendors may only ship
> Vista.  (Lenovo allows me to downgrade to XP so if I catch it
> misbehaving, I could try for support.  But I don't want to pay them
> $50 for the disks with which to downgrade.)

I think XP might have been the first to support using the PAT system.
You do have to go to a rather old CPU to not have that supported.
Unfortunately linux has only recently got close to being able to fully
use the PAT system instead of the MTRR.

> (I have a similar problem with my HP desktop.)
> 
> | There is nothing X can do to help the problem.  Linux could get their
> | PAT support completed (which they are working away at), which should
> | take care of it.
> 
> X could get more deeply into reorganizing MTRR values.  But PAT
> appears to be a much more sane way to go.

X should NOT try to guess what the MTRR should be.  User space has no
business messing with such things (you can crash the system if you play
with thte MTRR values that the BIOS set since you have no idea what SMM
code might be using them).

> Really?  Yuck.  Sounds like the kind of thing that manufacturers could
> be pressured to fix -- they probably promise 64-bit Vista support.

Most ignore 64bit vista so far.  No one uses it, so no one supports it
and hence no one uses it.  It took almost 18 months for intel to fix the
BIOS for one of their boards where they broke the MTRR setup in one
version and finally a year and a half later they fixed it in a new BIOS
that fully covered the ram.  Linux and 64bit windows were unusable
unless you told them to ignore parts of the ram in the system.  Gigabyte
only took a day or two to fix their BIOS when the same problem was
pointed out to them (they had used intel reference code in their BIOS
apparently) while intel argued that their BIOS was correct (even though
64bit windows took an hour to boot with 8GB ram in the system).

> Besides performance, is there an easy test for this?

You can look at the MTRR table and see what it is doing.  Newer linux
kernels have optional code to regenerate the MTRR table with "sane"
values, but you have to explicitly enable it from the kernel command
line and it doesn't always work right.

> It isn't so much the amount of RAM as the granularity of control thus
> required.  Dealing with big power-of-two-sized chunks takes no more
> registers than dealing with small ones.  The problem is when both
> co-exist.

If the BIOS would simply map memory better it would be simpler. Like ram
from 0 to 3GB, and from 4GB and up.  None of this 3.2 or 3.3GB crap that
they like to do to make the 32bit windows users get a little bit more
ram.  Then you can cover ram from 0 to 3GB in two MTRR entries and set
the default to uncached to cover the BIOS and roms and such, X can use
one entry for write combining, and the ram above 4GB can be covered in a
few more entries.

> I've written userland code to bust up overlapping MTRRs.  My version
> runs out of MTRRs on my ThinkPad.
> 
> There is a kernel patch to do the same thing.  But it accepts a
> "granularity" argument that allows it to use fewer.  I'm not sure that
> I believe that the result is a correct set of MTRR values.  I guess it
> is up to the ignorant user to specify the granularity and take
> responsibility for the consequences.

Well it tries its best but I think in some cases it runs out too and may
have to drop a bit of system ram from use to work in some cases.

> I'm slowly working on a version of my program to uncover only selected
> ranges.  I intend to use it only for the video buffer address space.
> For that, I think that there are enough MTRRs.
> 
> Do you know if anything on Linux other than X video drivers tries to
> manipulate MTRRs?

Nope.  I don't think anything else ever does.

> Apparently not grub 0.97 immediately after ntfsresize.  After the
> subsequent checkdisk, chainloading again works.

parted certainly breaks vista boot (with or without grub, makes no
difference).  The vista repair console fixes it nicely though.

> Is there a included-with-Vista program to toggle the boot flag on a
> partition?  Currently I boot a live Linux disk and use fdisk but my
> tablet doesn't have a built-in optical drive so that might be
> inconvenient.

I think it might be doable from the storage manager.

> I should have said that I used GParted.  I assume that that is a
> variant of parted but I don't know.

Parted with a GUI.

> GParted seems quite powerful.
> 
> One think that I don't like is that the resulting partition table gets
> good old fdisk worried.  Several partitions generate warnings like
> this:
> 	Partition 1 does not end on a cylinder boundary.
> I guess a granularity option for parted would be good too (perhaps it
> has one that I have not found).

Unless you run DOS, who cares if it lines up.

> I wanted to leave the Lenovo-supplied MBR so I was installing a boot
> sector on /dev/sda3.  Grub would not accept this.  Not actually having
> the /dev/sda3 path seems like a sufficient explanation but perhaps
> there is another.  Other grub behaviour suggests that it cares about
> the filename and not just the device inode.

Not sure.  Never had a problem with grub, other than needing grub2 in a
couple of cases (where GPT rather than MBR partitions were in use).

-- 
Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists