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 performance.
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 problem.
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: uncachable, count=1 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