Date: Mon, 4 Jun 2007 20:24:22 +0200
From: Andi Kleen <andi@firstfloor.org>
To: Ray Lee <ray-lk@madrabbit.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>,
       Matt Keenan <tank.en.mate@gmail.com>,
       Justin Piszcz <jpiszcz@lucidpixels.com>,
       Andi Kleen <andi@firstfloor.org>,
       Venki Pallipadi <venkatesh.pallipadi@intel.com>,
       linux-kernel@vger.kernel.org
Subject: Re: Intel's response Linux/MTRR/8GB Memory Support / Why doesn't the kernel realize the BIOS has problems and re-map appropriately?
Message-ID: <20070604182422.GA14275@one.firstfloor.org>
References: <Pine.LNX.4.64.0706011410130.3716@p34.internal.lan> <Pine.LNX.4.64.0706021610210.19116@p34.internal.lan> <4662869A.9030700@gmail.com> <200706040840.21593.jbarnes@virtuousgeek.org> <2c0942db0706040848y1d1c2ce9p521c65117244edf1@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2c0942db0706040848y1d1c2ce9p521c65117244edf1@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 895
Lines: 21

> Ick. Systems that used to boot fine would then panic on a kernel
> upgrade. That's rather rude for a condition that's merely an
> optimization (using all memory), rather than one of correctness. A
> panic seems entirely inappropriate.

No, when the MTRRs are wrong they would generally not work fine.
As soon as something uses the uncached memory things go incredibly
slow, slow enough to make the machine unusable. Sometimes you're
lucky and nothing important is in there, but only sometimes.

There is also no code in there currently to automatically limit
the memory; the user has to do that with mem=...

But I also don't like the panic.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/