From: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
To: Howard Chu <hyc@symas.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: MTRR initialization
Date: Fri, 21 Sep 2007 17:27:17 -0700 [thread overview]
Message-ID: <20070922002717.GA16353@linux-os.sc.intel.com> (raw)
In-Reply-To: <46EAB7DA.10507@symas.com>
On Fri, Sep 14, 2007 at 09:33:30AM -0700, Howard Chu wrote:
> Hi, was wondering if anyone else has been tripped up by this... I've got
> 4GB of
> RAM in my Asus A8V Deluxe and memory hole mapping enabled in the BIOS. By
> default, my system boots up with these MTRR settings:
>
> reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
> reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
> reg02: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
> reg03: base=0xc0000000 (3072MB), size= 256MB: write-combining, count=1
>
> The X server and various other programs try to add a mapping for my video
> card's buffer, at 0xd0000000, size=256MB, type=write-combining, and this
> always
> fails with a type mismatch error (old type is write-back). Apparently it's
> conflicting with mapping register 0. I can't just disable the existing
> settings
> and re-add them; the system hangs soon after disabling reg01.
>
> I guess the kernel must be getting the initial setup from the BIOS. I've
> hacked
> around this in mtrr/generic.c by explicitly changing the MTRR state in
> get_mtrr_state to split the first mapping into two; one at base 0 size
> 2048M
> and one at base 2048M size 1024M. So now I have this, which is pretty much
> what
> I wanted:
>
> reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
> reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
> reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
> reg03: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
> reg04: base=0xc0000000 (3072MB), size= 256MB: write-combining, count=1
> reg05: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1
BTW, having overlapping WC, UC regions make the end result UC. So in this
case, you may not be getting the desired performance.
>
> So the question is - was there an easier/correct way to do this?
>
> It might have been nice if the MTRR ioctls allowed the register number to
> be
> specified on the Set commands, though I'm not sure that would have helped
> in
> this case.
next prev parent reply other threads:[~2007-09-22 0:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-14 16:33 MTRR initialization Howard Chu
2007-09-14 17:12 ` Yinghai Lu
2007-09-16 16:08 ` Howard Chu
2007-09-16 17:53 ` Yinghai Lu
2007-09-16 18:40 ` Eric W. Biederman
2007-09-18 17:53 ` Howard Chu
2007-09-18 18:18 ` Eric W. Biederman
2007-09-19 21:52 ` Jesse Barnes
2007-09-20 6:50 ` Andi Kleen
2007-09-20 12:05 ` Avi Kivity
2007-09-20 12:10 ` Andi Kleen
2007-09-20 12:46 ` Avi Kivity
2007-09-20 15:03 ` Jesse Barnes
2007-09-20 17:08 ` Jesse Barnes
2007-09-22 0:27 ` Siddha, Suresh B [this message]
2007-09-22 0:46 ` Howard Chu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070922002717.GA16353@linux-os.sc.intel.com \
--to=suresh.b.siddha@intel.com \
--cc=hyc@symas.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.