Bug 10224

(In reply to comment #0)
> I own an ATI Radeon 8500 QL (AGP) (pci ids: 0x1002 x0514c).
> With the free driver, the system freezes in the minute with bos, in 10 minutes
> with openarena. Even a GL screensaver makes it freeze.
> The system is not totally crashed since the magic keys (alt+sysrq+ S,U,B) still
> enables to reboot.
All symptoms of a classic gpu lockup.

> The 6.6.x series has increased the stability somewhat over the 6.5.x but it's
> still very easy to freeze my system. I've tested various kernels (ranging from
> 2.6.17 to 2.6.20, all drivers from 6.5.x up to 6.6.3, a VIA motherboard and a
> SIS one.
If it only crashes with 3d apps, it's probably a bug rather in the mesa dri driver rather than the xorg ddx, you could try a newer version though there weren't any specific fixes for 8500 lockups for some time. Not sure why changing the ddx even would make a difference, could indicate some timing problem or bad interaction between ddx and dri. You could try disabling render accel, IIRC a long time ago there were some problems with that.

> I'ven't tried the fglrx driver so I cannot compare.
> 
> What can I do in order to provide you the needed data to pinpoint the actual
> bug?
To be honest, sporadic lockups are very hard to pinpoint, even hardware problems cannot be ruled out. I thought 8500 should work pretty stable now, AFAIK there are still r200-only hw-bug related lockups if using multi-pass ati fragment shaders (and possibly when using more than 2 textures even with single pass) for which we don't know the correct workaround (I've heard the 2-pass mode of mesa's afsmultiarb demo looks wrong and eventually locks up with r200) but this shouldn't cause issues with "standard" gl screensavers and openarena (which is just q3 engine right?), I've no idea what bos is.

I tried git of last week but it still crashed. I kept the following patches from http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/mesa/current/?sortby=date and I'll try without them:

# DRI modules are not under /usr/X11R6 anymore
Patch2:     mesa-6.5.1-default_dri_dir.patch
# Install EGL header files and fixes other minor compilations problems when enabling EGL
Patch3:     mesa-egl_support.patch
# static inline functions are broken on some architetures
Patch6:     mesa-6.5-drop-static-inline.patch
# In some cases radeon may have 0 bits depth
Patch7:     mesa-radeon-0depthbits.patch
# Fix compilation on x86_64 
Patch9:     mesa-6.5-x86_64-fix-build.patch
# Disable compilation of broken demos
Patch10:    mesa-6.5-xdemos_remove_broken.patch
# Fix linux-dri so it can be used for all archs (thanks Christiaan Welvaart)
Patch13:    Mesa-6.5.1-linux-dri-config.patch
# Disable some checks making Google Earth work on r300
Patch14:    mesa-6.5.1-google_earth_support.patch
# Fix moving DRI windows on the screen by updating the drawable info
Patch15:    mesa-6.5.2-mga_fix_dri_window_move.patch
# Fix some texture data corruption
Patch16:    mesa-6.5.2-texdata_corruption_fix.patch
# remove unfinished GLX_ARB_render_texture
Patch43:    mesa-6.5.2-no-ARB_render_texture.patch
# fix some crashs when a mesa context could not be found
Patch44:    mesa-6.5.2-check_context.patch

bos is http://www.boswars.org/

Mesa-7.0.1 compiled with -fno-strict-aliasing -fno-tree-vrp seems to behave better. I'll run more tests.

As a matter of fact, I still get the occasionnal lock-up on my R200 (FireGL 8800 / R200 QH), but never with Q3A/UT99/xscreensaver (GL). It is fairly reproductible with gl-117 though (third mission reliably crashes and leaves me with xorg eating 100% CPU), so it does not look like an hardware problem. I'll try boswars and report back.

Try latest Mesa (7.0.1) compiled with -fno-strict-aliasing -fno-tree-vrp.
Some code bits are now to break with aliasing & co.
For me, I consider it fixed (though I have to play with driconf in order to make boswars be smooth...)

Eventually, it does freezes quite easily with both boswars, openarena and warzone2100 (http://wz2100.net/) though I can sometimes kill it from the console[1], othertimes, I can only use kernel's magic sysrq keys and one time, I'd to hard reset the machine :-(

[1] the X server is then usable again but for the resolution which is
640x480 though xrandr pretends not:
# xrandr
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 1024 x 1024
VGA-0 connected 640x480+0+0 (normal left inverted right x axis y axis) 310mm x 230mm
   1024x768       85.0 +   84.9     75.1     70.1     60.0
   800x600        84.9     72.2     75.0     60.3     56.2
   768x576       100.0     79.4
   640x480        75.0*    72.8     60.0
   20x400        70.1

All xrandr calls succeeds w/o actually changing the resolution but krandrtray succeeds.

I tried several time to get a trace but I failed (maybe only the app/mesa is freezing, not the server itself).
Anyway, the problem seems to go away once mesa is compiled with -O1

We are compililing mesa with gcc-4.2.2 (but the bug already
existed when compiled with prior gcc releases) at -O2 level with:
- -fno-strict-aliasing
    strict aliasing is known to break some Mesa code
    https://bugs.freedesktop.org/show_bug.cgi?id=6046
    https://bugs.freedesktop.org/show_bug.cgi?id=9456
- -fno-tree-vrp
    tree VRP in gcc-4.2.1 triggers misrendering in Blender,
          and hard lock with compiz (in r300_state.c)
    https://bugs.freedesktop.org/show_bug.cgi?id=11380
    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32544

But it looks like it's not enough for r200 cards...

Mass version move, cvs -> git

I still have the card but I've no machine to plug it in for years.
Let's close as OLD