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. 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. 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?
(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
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.