learnings from upgrading a notebook

Tue Sep 2 23:33:08 UTC 2008

| From: Lennart Sorensen <lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org>

Thanks for you useful (as always) reply.

| On Mon, Sep 01, 2008 at 09:24:30PM -0400, D. Hugh Redelmeier wrote:

| > With this much memory, the BIOS sets up the variable MTRRs with
| > overlapping ranges.

| > The BIOS is not wrong.  X and the kernel are.  This is a long-standing
| > problem for some systems with 4G or more RAM.  I have a worse form of
| > it on my desktop.

| No actually the BIOS is wrong.

Why do you say that?  The Intel and AMD manuals make overlapping MTRR
values well-defined (with certain constraints on types).

|  Some BIOS vendors seem to assume you
| will use windows and hence PAT rather than MTRR to deal with things but
| for backwards compatibility and linux use, this is not nice.

"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 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.

| For most of these systems that do overlapping messed up MTRRs, 64bit
| windows often runs dreadfully slow as well, although it isn't so much a
| problem of overlapping MTRRs for that as for having some memory not
| covered at all and hence uncached.

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

Besides performance, is there an easy test for this?

| The MTRR is becoming rather hopeless though given it just doesn't have
| enough entries to deal with the amount of ram in modern machines
| anymore.

Yeah.

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.

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.

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?

| Vista chainloads fine from grub2.

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

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.

| > Using parted, I moved the /dev/sda3 partition.

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

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).

| > I don't know the right way to fix that grub.  I tried the technique
| > that is supposed to work with Fedora:
| > 
| > 	- boot live CD
| > 	- mount /dev/sda3 /tmp/root
| > 	- cd /tmp/root
| > 	- chroot /tmp/root
| > 	- grub-install /dev/sda3
| > 
| > This failed because there is no /dev/sda3 in that root filesystem.
| > Something must build it no the fly.
| 
| Using /dev/sda for grub worked great for me.

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.

| > For some reason that I don't understand, the sudoers file broke at
| > this point.  Mysterious.
| 
| No idea. :)

Me neither, but it went away after a reboot.
--
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