When I have 1gb of ram in my system, EXA is fast. When I have 4, EXA is slow as heck, and I get a message mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining set status page addr 0x08000000 cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 reg01: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 reg02: base=0x120000000 (4608MB), size= 256MB: 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 lspci devices 00:02.0 0300: 8086:2e22 (rev 03) (prog-if 00 [VGA controller]) Subsystem: 1043:8276 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at fe400000 (64-bit, non-prefetchable) [size=4M] Memory at d0000000 (64-bit, prefetchable) [size=256M] I/O ports at cc00 [size=8] Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCIe advanced features <?> 00:02.1 0380: 8086:2e23 (rev 03) Subsystem: 1043:8276 Flags: bus master, fast devsel, latency 0 Memory at fe800000 (64-bit, non-prefetchable) [size=1M] Capabilities: [d0] Power Management version 2 I have a g45 board, using latest GIT xf86-video-intel driver and libdrm. What can I do?
similar to bug#15360?
Yeah, same thing. Can XORG use PAT instead? I already updated my BIOS :\
I disabled "Memory Remap Feature" in my bios. It's some hack for Windows XP. Now I don't get that message, and EXA is decently fast with 6gb of ram. This bug can be closed, it's not a driver bug, sorry...
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= 256MB: write-back, count=1 reg03: base=0xc7e00000 (3198MB), size= 2MB: uncachable, count=1 reg04: base=0xc8000000 (3200MB), size= 128MB: uncachable, count=1 reg05: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1 Much better ;)
*** This bug has been marked as a duplicate of bug 15360 ***
Dylan: I think that you are losing 512MiB of memory without Remap (I have not checked carefully, and I don't have all the required information). With remapping, here's what my mtrr-uncover program suggests: $ ./mtrr-uncover --mtrrfile mtrr.sample.dylan 0x0d0000000-0x0dfffffff Initial MTRR configuration: 0 0x000000000-0x0ffffffff write-back 5 0x0c7e00000-0x0c7ffffff uncachable 6 0x0c8000000-0x0cfffffff uncachable 3 0x0d0000000-0x0dfffffff uncachable 4 0x0e0000000-0x0ffffffff uncachable 1 0x100000000-0x11fffffff write-back 2 0x120000000-0x12fffffff write-back Final MTRR configuration: 0' 0x000000000-0x07fffffff write-back 50' 0x080000000-0x0bfffffff write-back 51' 0x0c0000000-0x0cfffffff write-back 5 0x0c7e00000-0x0c7ffffff uncachable 6 0x0c8000000-0x0cfffffff uncachable 1 0x100000000-0x11fffffff write-back 2 0x120000000-0x12fffffff write-back Commands for /proc/mtrr to make these changes: disable=0 disable=3 disable=4 base=0x000000000 size=0x080000000 type=write-back base=0x080000000 size=0x040000000 type=write-back base=0x0c0000000 size=0x010000000 type=write-back
I'm actually losing a lot. The bios is reporting back only 3 gigs of ram if i have that remap function disabled, when I boot up the kernel it says BIOS BUG! mtrr values don't cover physical memory, losing 3 gigs I just posted on the asus forums, maybe they'll release a bios update. I'm done messing with this. 2 gigs is good enough for now. Maybe some day x will use PAT, or asus will release a bios update, or some xorg bug will be found and repaired.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=95ffa2438d0e9c48779f0106b1c0eb36165e759c 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=2048MB: write-back, count=1 reg03: base=0x180000000 (6144MB), size= 512MB: write-back, count=1 reg04: base=0x1a0000000 (6656MB), size= 256MB: write-back, count=1 reg05: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1 mtrr_chunk_size=128M mtrr_gran_size=128M Yay. I'm beginning to wonder if this is a bios bug, or maybe someone, somewhere is using a variable too small? ;) I run into problems marking a section for write-combining if a HUGE section is marked for write-back (4gb or greater it looks)
Re Dylan's message #8: I have some concerns about that kernel patch. It isn't clear to me that the rounding of MTRR region sizes that it does is guaranteed to work. It actually changes how some memory addresses are typed. The mtrr-uncover program leaves all addresses typed with the same type, even though this is accomplished via different MTRR values. On the other hand, Ingo and Linus are rather knowledgeable.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.