I have the same problem with ut2004 (r600g-64bit), and my kernel log is filled with
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
also.
(ut2003 simply crashes ingame with r600g-32bit , its all ok with r600c)

System:
Radeon HD Mobility 2600 (rv630)
amd64 architecture

d-r-t-git and 2.6.37 tested
libdrm, mesa, xf86-video-ati are all git master
xorg-server-1.9.3.901
(gentoo)

We (Jan and me) did some tests today and found out that the issue is probably related to the use of VBOs (or more specifically: not using them).

In ut2004 there is a option called 'UseVBO' for the OpenGL renderer. I guess enabling this one lets the engine use the 'ARB_vertex_buffer_object' extension. It turned out that in my ut2004 config it was enabled, but Jan had it disabled. So after enabling it for Jan the rendering suddenly worked. And when I disabled UseVBO on my system it suddenly failed and produced the black screen, plus the relocation parser errors in the kernel log.

I can only guess here, but maybe the problem is with Gallium's immediate mode implementation -- if that's how the engine submits vertices when ARB_vbo is not used.

The next thing we found out is even more interesting: In ut2003 there is no such option, so he had to stick to the 'immediate mode' rendering path. All the tests were done on Jan's system. We noticed that is was possible to get ingame when being logged in as root. This only worked for a short time, maybe like 10 seconds, before the game segfaulted. After it segfaulted, it wasn't possible any more to get ingame. The game just instantly segfaulted. Restarting X didn't help, only a full reboot did the trick.

Another thing that worked: Reboot, start ut03 as root, watch some game scenary for like 3 seconds, quickly exit the game, start ut03 as root, repear procedure...

The maximum amount of time we managed to get into game was three. After that it didn't work any more.

It was like we hit some memory leak, maybe in VRAM?

Then we switched over to ut2004 and disabled UseVBO there. We got the black screen (with the kernel messages) when we got ingame and then we waited a bit. But just like ut03 the game segfaulted after some seconds and we even managed it at one time to trigger the kernel OOM killer.

New tests on my system with ut2004. UseVBO is disabled, so I only get a black screen ingame.

I can still play though (by ear so to speak) and while doing this I watched memory consumption of the process:
Monitoring ut2004-bin with htop showed that during peak times the process has more than 50GiB virtual mem (VIRT) allocated. So there's clearly a mem leak here.

Could valgrind help to detect such a leak?

(In reply to comment #3)
> Monitoring ut2004-bin with htop showed that during peak times the process has
> more than 50GiB virtual mem (VIRT) allocated. So there's clearly a mem leak
> here.
> 
That's 64-bit ut2004, right?

> Could valgrind help to detect such a leak?
Probably, but it's certainly not going to make it any faster.

(In reply to comment #4)
> That's 64-bit ut2004, right?
Yes.

> Probably, but it's certainly not going to make it any faster.
That's a given. And it didn't work anyway, since it looks like that gentoo strips the library loader. valgrind apparantly doesn't like that and fails on startup.

Have to take another look when I find some time.

Looks like the problem got fixed by the recent changes to the vertex buffer upload code. Both ut2003 and ut2004 now work flawlessly.

Thanks Marek!