Fix for mtrr "overlapping" error.

[the_best_bear86]

I've decided to do a major rewrite of this first post to make it more easy to read and remove some of the less important text. I removed the section where you "manually" inserted the right mtrr value, since it was more difficult than other solutions. If you miss that part terribly or have any other suggestions you can always PM me. -------------------------------------------------------------------------------------------------------------
Last update: 2005-01-24
Change log:
* Added (hopefully) more correct LILO parameters.
* Changed the boot parameters from removing "mtrr", to adding "nomtrr"
* Some small changes


This post were written as a work-around to the problems with MTRR overlaping errors.

Only users who have the VESA framebuffer and fglrx drivers running at the same time have these problems (what I've seen so far)!!!

You should read this guide if you have this error when you run "dmesg" (or to see it easier, "dmesg |grep fglrx", without the ""'s of course)

fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel.
[fglrx] Maximum main memory to use for locked dma buffers: 1896 MBytes.
[fglrx] module loaded - fglrx 3.X.X [Dec 18 2003] on minor 0
mtrr: 0xe8000000,0x8000000 overlaps existing 0xe8000000,0x1000000 <----- This is what you
[fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)  <----- should look for.

You can double-check by doing:

cat /proc/mtrr

Check if you have these values:
reg00: base=0x00000000 ( 0MB), size= 512MB: write-back, count=1
reg01: base=0xd0000000 (3328MB), size= 128MB: write-combining, count=2
reg03: base=0xd8000000 (3456MB), size= 16MB: write-combining, count=2 <---- This value should correspond to your amount of gfx memory.

If you have this/these error(s), you should follow this guide. It will give a significant performance increase in newer games which use most of the gfx memory, especially when high-res textures are used (which use more memory).
--------------------------------------------------------------------------------------------------------------

Which FIX should I try?
Well, that depends. If you don't use the consoles that much, I guess that fix #1 is the one for you. It is also easier to apply. I run fix #2, since I use the console quite a lot and I can't stand the slow scrolling, the only downside is that you "waste" between 112Mb and 240Mb of the kernels 1GB of memory space.

--------------------------------------------------------------------------------------------------------------

FIX #1 (This fix is not recommended if you use the consoles a lot, since scrolling will be SLOW)

What you need to know:

Where to set the boot parameters

Where to find this information:

Where to set the boot parameter: If you use grub you should check /boot/grub/menu.lst or /boot/menu.lst depending on where your file is located. Open your menu.lst file and go to the line which says "kernel". There you should find something like:

For GRUB users:

kernel /boot/vmlinuz root=/dev/hda1 video=vesafb:ywrap,vga=0x31X

Now, simply add the option "nomtrr" in the example above, so the line reads:

kernel /boot/vmlinuz root=/dev/hda1 video=vesafb:ywrap,vga=0x31X,nomtrr

For LILO users:
You will have to open your lilo.conf (found in /etc, right?). Your file will hopefully look something like this:

# LILO configuration file
boot = /dev/hda3
delay = 30 
prompt
vga = ASK # Let user enter the desired modes
image = /vmlinuz
  append = "video=vesafb:mode:1024x768:nomtrr"
  root = /dev/hda3
  label = Linux

Then try adding :nomtrr after the mode (this is unverified, please report if this works!!). Finnish of with running "lilo".

Do a reboot, hopefully everything works as it should. Check dmesg if you still have errors, and second-check you /proc/mtrr. If you get no errors and your /proc/mtrr reads something like:

reg00: base=0x00000000 ( 0MB), size= 512MB: write-back, count=1
reg01: base=0xd0000000 (3328MB), size= 128MB: write-combining, count=2
reg03: base=0xd8000000 (3456MB), size= 128MB: write-combining, count=2

(The last register will only show up once X is started and the fglrx driver sets the MTRR's)

Then you know it worked, now go enjoy your better fps

As said in the begining, this will make scrolling in consoles VERY SLOW.
--------------------------------------------------------------------------------------------------------------

FIX #2

What you need to know:

Amount of video memory
Where to set the boot parameters

Where to find this information:

Amount of memory: Well you hopefully know this already . Check the box in which you got the card or if you realy don't know, do (as root):

lspci -v

and check for something similar to this:

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R300 ND [Radeon 9700] (prog-if 00 [VGA])
Subsystem: ATI Technologies Inc: Unknown device 0002
Flags: bus master, stepping, 66Mhz, medium devsel, latency 255, IRQ 11
Memory at d8000000 (32-bit, prefetchable) [size=128M] <---- Here's the info!!!
I/O ports at 9000 [size=256]
Memory at e9000000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2

Where to set the boot parameter: This might be a bit trickier. If you use grub you should check /boot/grub/menu.lst or /boot/menu.lst depending on where your file is located. Open your menu.lst file and go to the line which says "kernel". There you should find something like:

kernel /boot/vmlinuz root=/dev/hda1 video=vesafb:ywrap,mtrr,vga=0x31X <---- here you need to add the code found below.

For Grub users:

vram:{your ram amount in Mb}

Example: kernel /boot/vmlinuz root=/dev/hda1 video=vesafb:ywrap,mtrr,vga=0x31X,vram:128

Important!!! Don't forget to add a comma (,) before you add the vram option

For LILO users:

# LILO configuration file
boot = /dev/hda3
delay = 30 
prompt
vga = ASK # Let user enter the desired modes
image = /vmlinuz
  append = "video=vesafb,mtrr,vga=0x31X,vram:128"
  root = /dev/hda3
  label = Linux

just add your amount of video memory at the end of the line, like above (this is unverified, please report if this works!!). Then run lilo.

Do a reboot, hopefully everything works as it should. Check dmesg if you still have errors, and second-check you /proc/mtrr. If you get no errors and your /proc/mtrr reads something like:

reg00: base=0x00000000 ( 0MB), size= 512MB: write-back, count=1
reg01: base=0xd0000000 (3328MB), size= 128MB: write-combining, count=2
reg03: base=0xd8000000 (3456MB), size= 128MB: write-combining, count=2

Then you know it worked, now go enjoy your better fps

[WhO_KnOwS]

Nice one. Will try it out...

[the_best_bear86]

You can check if it worked, if you type

cat /proc/mtrr

It should look something like this:

reg00: base=0x00000000 ( 0MB), size= 512MB: write-back, count=1 <-- RAM
reg01: base=0xd0000000 (3328MB), size= 128MB: write-combining, count=2 <-- AGP Aparture
reg03: base=0xd8000000 (3456MB), size= 128MB: write-combining, count=4 <-- video mem.

check if the vid-mem reg. reports as much memory as your gfx has.

[WhO_KnOwS]

I'm looking it it now. A few questions:
1.) Mem @ 0xd8000000/27 <--- You say that the 8000000 is important. Does it have to be /27, cause all I have is /26.
2.)

reg00: base=0x00000000 (   0MB), size= 512MB: write-back, count=1
reg01: base=0xf8000000 (3968MB), size=  64MB: write-combining, count=2
reg02: base=0xf4000000 (3904MB), size=  16MB: write-combining, count=1

This is before changing. I guess reg02 is my card ey?

[WhO_KnOwS]

Ok. Here is what I did:
dmesg |grep mtrr gives me the error.

cat /var/log/XFree86.0.log |grep ATI gives me this:

(--) PCI:*(1:0:0) ATI Technologies Inc Radeon R300 AD [Radeon 9500 Pro] rev 0, Mem @ 0xf4000000/26, 0xeb800000/16, I/O @ 0xd800/8, BIOS @ 0xf3fe0000/17
(--) PCI: (1:0:1) ATI Technologies Inc unknown chipset (0x4164) rev 0, Mem @ 0xe

My card has 64mb so ---> 0x4000000

cat /proc/mtrr gives me:

reg00: base=0x00000000 (   0MB), size= 512MB: write-back, count=1
reg01: base=0xf8000000 (3968MB), size=  64MB: write-combining, count=2
reg02: base=0xf4000000 (3904MB), size=  16MB: write-combining, count=1

echo "disable=3" >| /proc/mtrr

disables the card.
To start it I use:

echo "base=0xf4000000 size=0x4000000 type=write-combining" >| /proc/mtrr

which should be fine. dmesg |grep still gives me the same error. At least cat /proc/mtrr now gives me 64mb as it should.

[the_best_bear86]

Great, if cat /proc/mtrr says 64Mb, it is activated.

I don't get the boot error anymore (which is kind of strange, since my boot-script "mtrr-fix" sets in after fglrx is initiated, but I don't complain). Make a boot-script and try if you still get the boot-error. it isn't that important, as long as /proc/mtrr reports your gfx memory as it should.

Here's my boot-script (you need to change the values):

#!/bin/bash

echo "disable=3" >| /proc/mtrr

echo "base=0xd8000000 size=0x8000000 type=write-combining" >| /proc/mtrr

Try if you get any performance gains in UT2003 (if you have it...). I've noticed a good performance gain. It seems like particles (smoke and stuff) as well as bigger maps run better. I would aproximate my speeds somwhere like 10fps from m$ speeds.

[WhO_KnOwS]

Error fixed. Just added the path to the script in /etc/conf.d/local.start (that's for gentoo).

[the_best_bear86]

Very well please do some testing, I'd like to know if erverybody get this performance gain. I guess that it's more noticable in newer games (that use most of your vid-mem. with large textures). Haven't tried q3, but I don't think I will notice any major difference there.

[neuron]

if cat /proc/mtrr shows 512/128/128 it works right? I don't have to screw with it? I do get mtrr errors, but I don't really care about em if it works

[WhO_KnOwS]

Americas Army has at least a 15% increase in FPS. Tnx for your help.

[the_best_bear86]

It's always nice the help people

I think that this is a quite unknown error, everthing seems to work. You'll only see it if you check your boot messages, and how many people do that if it everything works.

Orginally posted by neuron
if cat /proc/mtrr shows 512/128/128 it works right? I don't have to screw with it? I do get mtrr errors, but I don't really care about em if it works

Ok, I was a bit tired yesterday (night as a matter of fact...). You should look an see if you get

[fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)

then you should look into it. If you "just" get the

mtrr: 0xd8000000,0x8000000 overlaps existing 0xd8000000,0x1000000

You might not have a problem.

Best were if you could post your /proc/mtrr output, your boot-error message and the PCI line in the XFree86.0.log.

I would be glad if you did so, because then I can see if this problem varies in apperiance, and I might be able to fix that too.

[neuron]

I'll reboot and check now, been playing nwn and my entire log was full of.
[fglrx:firegl_agp_lock_pages] *ERROR* agp_allocate_memory_phys_list failed

//edit, reboot, ati output normal (I'd usualy get mtrr info after starting something, I remember that much), started fgl_glxgears, log full of the agp_lock error. I'll try to resolve that and then check mtrr

[neuron]

after the fix I didn't see an increase in fgl_glxgears performance. But the mtrr went from

reg02: base=0xd8000000 (3456MB), size= 128MB: write-combining, count=7
to
reg02: base=0xd8000000 (3456MB), size= 128MB: write-combining, count=6

noticed the only thing that changed was the count.

[the_best_bear86]

ok, I know I can get errors when i run ut2003, and shut it down. Sometimes I get sigsev, which gives me this error:

"mtrr: no MTRR for d8400000,100000 found". I think these are software errors (ie. program code), the program has set a value, but when it crashes (or some kind of error occur) it can't find the values. If it is this kind of error It's probably from an other source, not that the mtrr registers are set up wrong.

I don't really know what the count means, but it doesn't change performance (that I've noticed). You should be fine with mtrr, it reports your full vid-mem.

The AGP_lock stuff you talked about probably has something to do with agp_gart (just a guess).

//Edit: You probably won't notice any performance difference in glxgears, you need to try a more memory-demanding app. UT2003 or Americas Army are good apps. to try with.

[WhO_KnOwS]

After some more testing:
Both UT2003 and AA have fps higher for about 10% at the "normal" textures setting. The % goes up if I set a higher setting.

P.S. I've told Kombatant to add this thread to the important threads list. Good job the_best_bear86

[the_best_bear86]

Originally posted by WhO_KnOwS
P.S. I've told Kombatant to add this thread to the important threads list. Good job the_best_bear86

Thanks.

[dragondestroyer]

I have the same error but I am a little confused and must have done something wrong as it didnt work.
I have a 9500 pro with 128mb. Here is the relevant information.

dmesg:

request_module: failed /sbin/modprobe -- char-major-226-0. error = 256
fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel.
[fglrx] Maximum main memory to use for locked dma buffers: 1896 MBytes.
[fglrx] module loaded - fglrx 3.7.0 [Dec 18 2003] on minor 0
mtrr: 0xe8000000,0x8000000 overlaps existing 0xe8000000,0x1000000
[fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)
Fire GL built-in AGP-support
Based on agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 816M
agpgart: Detected an Intel 875G Chipset with integrated grapics.
agpgart: unable to get memory for graphics translation table.
[fglrx] AGP detected, AgpState = 0x1f004a1b (hardware caps of chipset)
agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
[fglrx] AGP enabled, AgpCommand = 0x1f004312 (selected caps)
[fglrx] free AGP = 121909248
[fglrx] max AGP = 121909248
[fglrx] free LFB = 116391936
[fglrx] max LFB = 116391936
[fglrx] free Inv = 0
[fglrx] max Inv = 0
[fglrx] total Inv = 0
[fglrx] total TIM = 0
[fglrx] total FB = 0
[fglrx] total AGP = 32768



cat /var/log/XFree86.0.log | grep ATI:

(**) | |-->Device "ATI Graphics Adapter"
(--) PCI:*(1:0:0) ATI Technologies Inc Radeon R300 NE [Radeon 9500 Pro] rev 0, Mem @ 0xe8000000/27, 0xf9000000/16, I/O @ 0xa000/8
(--) PCI: (1:0:1) ATI Technologies Inc Radeon R300 [Radeon 9500 Pro] (Secondary) rev 0, Mem @ 0xf0000000/27, 0xf9010000/16


cat /proc/mtrr

reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0xe8000000 (3712MB), size= 16MB: write-combining, count=1
reg02: base=0xe0000000 (3584MB), size= 128MB: write-combining, count=1


Any help would be greatly appreaciated.

[WhO_KnOwS]

Originally posted by dragondestroyer
I have the same error but I am a little confused and must have done something wrong as it didnt work.
I have a 9500 pro with 128mb. Here is the relevant information.

dmesg:

request_module: failed /sbin/modprobe -- char-major-226-0. error = 256
fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel.
[fglrx] Maximum main memory to use for locked dma buffers: 1896 MBytes.
[fglrx] module loaded - fglrx 3.7.0 [Dec 18 2003] on minor 0
mtrr: 0xe8000000,0x8000000 overlaps existing 0xe8000000,0x1000000
[fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)
Fire GL built-in AGP-support
Based on agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 816M
agpgart: Detected an Intel 875G Chipset with integrated grapics.
agpgart: unable to get memory for graphics translation table.
[fglrx] AGP detected, AgpState = 0x1f004a1b (hardware caps of chipset)
agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
[fglrx] AGP enabled, AgpCommand = 0x1f004312 (selected caps)
[fglrx] free AGP = 121909248
[fglrx] max AGP = 121909248
[fglrx] free LFB = 116391936
[fglrx] max LFB = 116391936
[fglrx] free Inv = 0
[fglrx] max Inv = 0
[fglrx] total Inv = 0
[fglrx] total TIM = 0
[fglrx] total FB = 0
[fglrx] total AGP = 32768



cat /var/log/XFree86.0.log | grep ATI:

(**) | |-->Device "ATI Graphics Adapter"
(--) PCI:*(1:0:0) ATI Technologies Inc Radeon R300 NE [Radeon 9500 Pro] rev 0, Mem @ 0xe8000000/27, 0xf9000000/16, I/O @ 0xa000/8
(--) PCI: (1:0:1) ATI Technologies Inc Radeon R300 [Radeon 9500 Pro] (Secondary) rev 0, Mem @ 0xf0000000/27, 0xf9010000/16


cat /proc/mtrr

reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0xe8000000 (3712MB), size= 16MB: write-combining, count=1
reg02: base=0xe0000000 (3584MB), size= 128MB: write-combining, count=1


Any help would be greatly appreaciated.

Do:

echo "disable=2" >| /proc/mtrr

and then:

echo "base=0xe8000000 size=0x8000000 type=write-combining" >| /proc/mtrr

All of this must be in a boot-up script. Make one like the_best_bear86 posted higher and add it to boot (sorry but I don't know about specific distros)

[the_best_bear86]

Originally posted by dragondestroyer
cat /proc/mtrr

reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0xe8000000 (3712MB), size= 16MB: write-combining, count=1
reg02: base=0xe0000000 (3584MB), size= 128MB: write-combining, count=1

Actually you should disable "reg01". You see the "reg01: base=0xe8000000", this match the number you get in the boot error "mtrr: 0xe8000000,0x8000000 overlaps existing 0xe8000000,0x1000000"

You should do:

echo "disable=1" >| /proc/mtrr

then:

echo "base=0xe8000000 size=0x8000000 type=write-combining" >| /proc/mtrr

[WhO_KnOwS]

Woops. Tnx for the correction...

[spyke]

This is also another nasty bug that needs fixing, the driveres should set the MTRR's properly the first time like they do with my system.

reg00: base=0x00000000 ( 0MB), size= 512MB: write-back, count=1
reg01: base=0xc0000000 (3072MB), size= 256MB: write-combining, count=2
reg02: base=0xd0000000 (3328MB), size= 128MB: write-combining, count=1
reg05: base=0xc0000000 (3072MB), size= 256MB: write-combining, count=1

[the_best_bear86]

Originally posted by WhO_KnOwS
Woops. Tnx for the correction...

No problem

[Aiki_}{_Ghost]

Sorry to show my ignorance here but the last time I had to use hex was about 30 yrs ago
I get the idea and everything but my implementation leaves a b it to be desired. cat /proc/mtrr gives me

bash-2.05b$ cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1
reg01: base=0xd0000000 (3328MB), size= 128MB: write-combining, count=2
reg02: base=0xd8000000 (3456MB), size= 16MB: write-combining, count=4
bash-2.05b$

DMESG gives me
bash-2.05b$ dmesg | grep -B2 mtrr
PCI: PCI BIOS revision 2.10 entry at 0xfb4a0, last bus=2
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
--
[<c01094bb>] syscall_call+0x7/0xb

mtrr: 0xd8000000,0x8000000 overlaps existing 0xd8000000,0x1000000
[fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)
bash-2.05b$

Followed by xfree giving

bash-2.05b$ cat /var/log/XFree86.0.log | grep ATI
(**) | |-->Device "ATI Graphics Adapter"
(--) PCI:*(2:0:0) ATI Technologies Inc unknown chipset (0x4e4a) rev 0, Mem @ 0xd8000000/27, 0xe9000000/16, I/O @ 0xd000/8
(--) PCI: (2:0:1) ATI Technologies Inc unknown chipset (0x4e6a) rev 0, Mem @ 0xe0000000/27, 0xe9010000/16
(II) Module fglrx: vendor="Fire GL - ATI Research GmbH, Germany"


=====================================================

So, my understanding so far is

echo "disable=2" >| /proc/mtrr

echo "base=0xe8000000 size=??????????? type=write-combining" >| /proc/mtrr

and then add the path to that in a script to /etc/conf.d/local.start and all is set to go?

Problem I have assuming the above is right, is what's the value I should be entering for the 9800xt with 256Mb onboard?

I found an online converter that gave me something like 00001000 but to my hex ignorant eyes that doesn't look right

[WhO_KnOwS]

Disable=2
And 256 is 0x10000000

And the path to the script work in gentoo (gentoo has a rc system that is different from other distributions). Not sure how other distros handle that.

[Aiki_}{_Ghost]

Cheers, thx for the quick reply m8 i'll give it a try now I'm running Gentoo as well so all should be ok there, just this hexadecimal stuff that has me head cabbaged

[Aiki_}{_Ghost]

Noob alert I must have messed up something somewhere

I dropped

#!/bin/bash

echo "disable2" >| /proc/mtrr

echo "base=0xd8000000 size=0x10000000 type=write-combining" >| /proc/mtrr

into /sbin
and added /sbin/mtrr.sh to etc/conf.d/local.start
but dmesg gives me a failed to start local message and dmesg shows a not alligned error

bash-2.05b$ dmesg | grep mtrr
mtrr: v2.0 (20020519)
mtrr: base(0xd8000000) is not aligned on a size(0x10000000) boundary
mtrr: 0xd8000000,0x8000000 overlaps existing 0xd8000000,0x1000000
[fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)
bash-2.05b$

Probably not the best time to be learning about startup scripts either but, running the two commands from the terminal alone doesn't seem to show any change other than count is now equal to 2

bash-2.05b# cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size=1024MB: write-back, count=1
reg01: base=0xd0000000 (3328MB), size= 128MB: write-combining, count=2
reg02: base=0xd8000000 (3456MB), size=  16MB: write-combining, count=2
bash-2.05b#

[the_best_bear86]

Ok, I saw what you wrote...

//Edit:

(Post the "lspci -v" output from your gfx, so we can see if it reports 256Mb.)

(Try to enable 128Mb (0x8000000), and se if it works.)
//Edit2:

it seems that: echo "disable=3" >| /proc/mtrr doesn't work if you type it in a console in X. You don't have to shut down X, but you have to type it in in a terminal "outside" of X.

[Aiki_}{_Ghost]

Thx for the help guys and sorry for the delay in response as i'm recompiling the kernel at the same time as I discovered this problem



lspci -v gives

00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev c1) (prog-if 00 [Normal decode])
        Flags: bus master, 66Mhz, medium devsel, latency 32
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
        I/O behind bridge: 0000d000-0000dfff
        Memory behind bridge: e8000000-e9ffffff
        Prefetchable memory behind bridge: d8000000-e7ffffff



02:00.0 VGA compatible controller: ATI Technologies Inc: Unknown device 4e4a (prog-if 00 [VGA])
        Subsystem: ATI Technologies Inc: Unknown device 0002
        Flags: bus master, stepping, 66Mhz, medium devsel, latency 255, IRQ 10
        Memory at d8000000 (32-bit, prefetchable) [size=128M]
        I/O ports at d000 [size=256]
        Memory at e9000000 (32-bit, non-prefetchable) [size=64K]
        Expansion ROM at <unassigned> [disabled] [size=128K]
        Capabilities: [58] AGP version 3.0
        Capabilities: [50] Power Management version 2

02:00.1 Display controller: ATI Technologies Inc: Unknown device 4e6a
        Subsystem: ATI Technologies Inc: Unknown device 0003
        Flags: stepping, 66Mhz, medium devsel
        Memory at e0000000 (32-bit, prefetchable) [disabled] [size=128M]
        Memory at e9010000 (32-bit, non-prefetchable) [disabled] [size=64K]
        Capabilities: [50] Power Management version 2

bash-2.05b#

I'm currently using the ChipID workaround to get the 9800xt using 3d

[the_best_bear86]

Ok, this ChipId, what does it do?

lspci -v reports just 128Mb, which could be a problem.

"Memory at d8000000 (32-bit, prefetchable) [size=128M]"

The other I edited my post above:

it seems that: echo "disable=3" >| /proc/mtrr doesn't work if you type it in a console in X. You don't have to shut down X, but you have to type it in in a terminal "outside" of X.

[Aiki_}{_Ghost]

The Chip Id is just a con to get the ati drivers to think the 9800xt is a 9800pro until the drivers support it, without it glxgears is at about 300fps and no games run, with it I get 4-5000 + 3d

XF86Config-4

Section "Device"
    Identifier                          "ATI Graphics Adapter"
    Driver                              "fglrx"
# === Misc Options ===
    Option "UseFastTLS"                 "0"
    Option "BlockSignalsOnLock"         "on"
    Option "UseInternalAGPGART"         "no"
    Option "ForceGenericCPU"            "no"
#    BusID "PCI:2:0:0"    # vendor=1002, device=4e4a
ChipID 0x4e48
    Screen 0
EndSection

I'll try from outside x and see what that does for me