Could it be (in the end) the same bug I described last meeting?
glxgears in the background, q3a overlapping a bit
and you get corruption in q3a.
(I have an old Radeon7500, DRI from current trunk, kernel 2.4.20)
1) After reading your email, I tried ipers and
glxgears (overlapping) -> corruptions in ipers
2) 2x ipers -> corruptions, after a while: Xserver hangs,
[drm:radeon_lock_take] *ERROR* 6 holds heavyweight lock
killall -KILL ipers remotely
3) trying to reproduce it: after starting one ipers -> hang,
at least after moving a terminalwindow over it. dmesg shows
a new drm-related line:
[drm:radeon_lock_take] *ERROR* 4 holds heavyweight lock
4) trying 3) a few more times: same result, Xserver didnt
"recover" from this strange state, I wasnt able to run
ipers and moving another window over it without getting
an Xserver hang.
5) next day: restarted box with the newest radeon.o
kernelmodule (after Davids merges)...
6) trying a few other apps: glxgears + arkhart
(arkhart.nekeme.net) even could show corruption when
glxgears isnt overlapping with it or even when glxgears
7) tried glxgears + teapot from Mesa-demos: corruption, you
see it better when both are overlapping (glxgears behind
(To the q3a-problem keith gave me a hint to look
into radeon_lock.c, at DRI_VALIDATE_DRAWABLE_INFO,
add printfs and watch the cliprects. After that
maybe going to radeon_ioctl.c/radeonFireCmdBuffer and
maybe to kernel/radeon_state.c
Unfortunately I didnt have enogh time to do something :/ )