On Fri, Aug 11, 2006 at 11:50:31AM +0200, Andi Kleen wrote:
The mtrr type mismatch messages are relatively
harmless by itself --
they happen even on perfectly working machines.
In particular uncachable->write combing is a standard transition that
happens often -- the BIOS left a uncachable memory region and the
X server or the frame buffer decides to turn it WC for better
Well, they aren't 'taking', at least not in so far as /proc/mtrr
displays, nor in how X performs.
> 3) How do
I get the system to put the IOMMU somewhere in the range
> it stole under 4G (so Linux can use it)? Can Linux move this on
> its own accord?
The IOMMU should work, you just lose 128MB of memory because its
aperture will be mapped over memory as fallback. I don't think that is your
I tried commenting out the bit of code in the kernel that detects
apertures addressed over 4G and ignores them. This removed the
line from dmesg that said: "Aperture from northbridge cpu 0 is
greater than 4G. Ignoring." But this remained:
PCI-DMA: Disabling IOMMU.
I did not look into the PCI code to see why it's choosing to do
this, but I assumed it was unprepared to use a 64-bit IOMMU.
Linux can move
this on it's own accord, but until you fix the
MTRRs (which Linux can't currently do),
What Linux can't do is to fix it up automatically.
But it should be possible to do it manually after boot (although the interface
is a bit weird). See /usr/src/linux/Documentation/mtrr.txt
The MTRR driver should be able to change any MTRRs using this.
reg00: base=0xc0000000 (3072MB), size=1024MB:
reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
Looking at your log it might be enough to change reg01 to end at 3072MB
Documentation/mtrr.txt doesn't tell me how to do that. If I delete
register 1, the system will crash (hard hang). If I try to add
any region that overlaps with register 1 (but doesn't overlap with
register zero - these get errored out and appear to make no change),
the count on register one gets incremented and nothing changes.
I've toyed with the idea of hacking into the kernel mtrr code - when
the mtrr is detected/read at boot time, when hopefully one might
disable interrupts and initialize the mtrr from scratch without
anything else going on.
Do you think that tactic would bear fruit?
Another option to get the machine working quickly
might be to take out
1 or 2GB of memory. Most of these problems only happen because many BIOS
are not very good at handling memory bumping into the PCI hole.
Right, I thought of that last night and wished I'd thought of it
yesterday, I'll give this a shot.
David W. Hankins "If you don't do it right the first time,
Software Engineer you'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins