Bug 21537

This is a GPU hang.  Please attach your xorg log and config.  You might want to try with with the r300 driver from the radeon_rewrite branch of mesa.

Created attachment 25423 [details]
xorg.conf

Created attachment 25424 [details]
xorg.log

Created attachment 25425 [details]
kernel log when I enabled drm debug after freeze

Intresting point is that if I try to reproduce the bug with debug enabled in drm it never locks. So maybe this is some timing problem in driver. (Some locking missing?)

I have tested radeon-rewrite already and same freeze happens there too.

This looks to be 3D related, but does updating to the latest ddx from git help (git master of xf86-video-ati)?

I have 5 days old version in /opt/local/lib/xorg/modules :)

It was at commit 7d9f643ae3d07e51e644a5979ca90bc2c102bc89

I can try using updated ddx, radeon-rewrite and modesetting-gem if you think there might be some kind of fix in the last 5 days.

please try grabbing the latest code.  the relevant commits are:

http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=1f70c9f05df9017d87b37f887e1eccd6d0568a02
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=a1c64ea5224009779ccad66b0f84d861eae966ac

Now using the latest radeon-rewrite, libdrm  modeseting-gem (including kernel modules but no mode setting because failing to initialise memory manager) and latest ddx everything works.

But when I try to use latest ddx with old mesa it hard locks now already level preview. (Doesn't even respond if trying to probe with nmap scan)

(In reply to comment #8)
> Now using the latest radeon-rewrite, libdrm  modeseting-gem (including kernel
> modules but no mode setting because failing to initialise memory manager) and
> latest ddx everything works.

Is the DRI enabled properly in that case?  Just want to make sure it's not falling back to software.

yes. xmoto would run around 0.5 fps if using software mesa. 

btw, I jsut noticed a weird small freeze about a second later that lock used to happen. Now it take about 200-500ms frame hit for no reason that I can see. I can reproduce this every time too. (geometry and texture loads should be far from x1400 card limits unless xmoto is very badly written)

Some more info:
I found stable combination also for mesa_7_4_branch.
That includes 
- mesa_7_4_branch head
- libdrm master head (also has to install kernel modules)
- xf86-video-ati master head

I tried to bisect for the problem in 7_4 branch and ddx separately but nether turned anything up (only in last 10 days). So here is happening some magic now that I don't understand. Problem might be that I only restarted X and not rebooted between testing ddx versions ...
Then I try to test running with stock drm modules from ubuntu jaunty. Not very promising experience as system paniced quite frequently. (3 times in about 10 minutes)

So I didn't find what was causing the bug in first place but now it seems like fixed.

Now I just looked more to kern.log and output looks very bad to me. Seems like there is buffer overflow or stack overflow that affects debug output. So is it possible for opengl apps to cause that or maybe some kind of buffer overflow in video memory?

I remember seeing a lot of texture artefacts if running two opengl applications same time. Seems like 2nd one overwrites some of memory reserved by first one. Running 2 instances of warzone shows the problem very clearly. but it is enough for minimal random texture corruption to run xmoto and neverput same time. (I guess kernel memory manager will fix this issue but it could still cause some problems)

I am having a similar lockup problem (see https://bugs.freedesktop.org/show_bug.cgi?id=21849). Can you try reverting to original Ubuntu packages and installing kernel 2.6.29.3 from # KernelMainlineBuilds PPA [0] and see if that fixes your lockup as with me?

I am bisecting between 2.6.29 and 2.6.30-rc1 right now.

[0] https://wiki.ubuntu.com/KernelMainlineBuilds

This was fixed in linux 2.6.30 final, the corresponding Ubuntu bug was also fixed some time ago.