Re: questions about x86: mtrr cleanup for converting continuous to discrete layout

[Dylan Taft]

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: uncachable, count=1
reg06: base=0xc8000000 (3200MB), size= 128MB: uncachable, count=1

and with Yinghai Lu's patches in git tip, with working write-combining mark
reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 128MB: write-back, count=1
reg03: base=0xc7e00000 (3198MB), size=   2MB: uncachable, count=1
reg04: base=0x100000000 (4096MB), size=2048MB: write-back, count=1
reg05: base=0x180000000 (6144MB), size= 512MB: write-back, count=1
reg06: base=0x1a0000000 (6656MB), size= 256MB: write-back, count=1
reg07: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/