I think a workaround in the kernel is absolutely necessary.  A lot of

newer motherboards have this issue, where a whole section of memory

will be marked as write-back, and write-combining can't be

embedded/nested.

As far as I'm aware, changing MTRRs won't make a system unstable,

especially if done so early on, when the kernel is starting up.  All

it does is change the behavior on how the CPU will cache write

requests to memory.  All system memory should be marked as write-back,

how many MTRRs are used to do this...I'm not sure if it exactly

matters.  You can set MTRR_SPARE_REG_NR and control how many MTRR

slots the code will use.
Is it legal to mark a write-combining range within a write-back range?
Ideally, maybe adding a minimal amount of MTRRs might be best, as D.

Hugh Redelmeier's userspace app does, but I think a fix for this in

the _kernel_ is an absolute must for 2.6.27.  Weather a range that has

to be marked for write-combining is just "uncovered", or weather

ranges are entirely automatically generated in chunks, either should

work, but Hugh's suggestion might save MTRR entries in practice?
I'm no kernel dev, I code a bit here and there, but I spent a LOT of

time researching this when I ran into the problem myself on my new PC.

 There's a lot of posts about it too in the intel bug tracker for

people with newer boards and the g45 chipset.  Most users shouldn't

have to worry about this, and it should, "just work".
I don't think this should be pulled unless a different fix is in place

in the kernel.
Thanks!
Here's what bios does with my MTRRs, write combining can't be set up

for my video card

reg00: base=0x1b0000000 (6912MB), size= 256MB: uncachable, count=1

reg01: base=0x1c0000000 (7168MB), size=1024MB: uncachable, count=1

reg02: base=0x00000000 (   0MB), size=8192MB: write-back, count=1

reg03: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1

reg04: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1

reg05: base=0xc7e00000 (3198MB), size=   2MB...
[ message continues ]

| From: Dylan Taft <d13f00l@gmail.com>
Thanks for your reply.
| To: linux-kernel@vger.kernel.org, yinghai@kernel.org, hugh@mimosa.com

| Subject: Re: questions about x86: mtrr cleanup for converting continuous to

|     discrete layout

|

| I think a workaround in the kernel is absolutely necessary.  A lot of

| newer motherboards have this issue,
I agree.
| where a whole section of memory

| will be marked as write-back, and write-combining can't be

| embedded/nested.
To be more clear:
Uncachable can be nested within write-back but write-combining cannot

be nested within write-back.  These newer BIOSes, when they see 4GiB

or more of RAM, nest an uncachable MTRR for a video buffer inside a

larger write-back region.
The video driver cannot simply change the type of the inner MTRR

because write-combining cannot be nested within write-back.
| As far as I'm aware, changing MTRRs won't make a system unstable,

| especially if done so early on, when the kernel is starting up.  All

| it does is change the behavior on how the CPU will cache write

| requests to memory.
Two kinds of stability issues:
- if the MTRRs are being changed while other things are going on, it

  may be the case that memory accesses are performed with an improper

  configuration.
  This is quite possible if the changes are from a userland program,

  like mine.  It might happen in a kernel-based version if

  insufficient locking is performed.
- wise people have said that SMM code may make assumptions about MTRR

  settings.  Here are a couple of random messages that touch on this:
	http://lkml.org/lkml/2008/4/28/201

	http://lkml.org/lkml/2008/4/29/522
|  All system memory should be marked as write-back,

| how many MTRRs are used to do this...I'm not sure if it exactly

| matters.  You can set MTRR_SPARE_REG_NR and control how many MTRR

| slots the code will use.
There are only 8 MTRRs on current hardware, as far as I know.  You

cannot use more.  If you use 8 or fewer, the number prob...
[ message continues ]