got Xorg lockups with an ATI Radeon 9250, xorg 6.8.2-r6, linux 2.6.15-r1. After upgrade to xorg 7.0-r1 and linux 2.6.15-r4 I got a lockup as well. The lockup usually occurs while a xscreensaver hack is active. I got a lockup outside of xscreensaver earlier, and switched xscreensaver blanking off for testing. With xorg 6.8.2 the lockup occured in the hypercube hack a few times, and the hack was apparently displayed incorrectly, there were some random line segments scattered on the screen in addition to the cube. The machine was either inacessible or there was an X process running in a tight loop and unkillable, with no way to change what is displayed on the screen. With xorg 7 I got a lockup in polytopes. And in hypercube as well. After the lockup polytopes was the process that used most cpu time, when I killed it X used most cpu time. It was again unkillable. When X is looping and cannot be killed top says there is >99% system cpu time. I tried to replace the video card with another one of the same type, and remove the DVB card to improve airflow. I got a lockup again. Anyway, I do not think that hypercube is very GPU intensive, and it displays incorrectly from the very start. 00:00.0 Host bridge: Intel Corporation 82845 845 (Brookdale) Chipset Host Bridge (rev 03) 00:01.0 PCI bridge: Intel Corporation 82845 845 (Brookdale) Chipset AGP Bridge (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 12) 00:1f.0 ISA bridge: Intel Corporation 82801BA ISA Bridge (LPC) (rev 12) 00:1f.1 IDE interface: Intel Corporation 82801BA IDE U100 (rev 12) 00:1f.2 USB Controller: Intel Corporation 82801BA/BAM USB (Hub #1) (rev 12) 00:1f.3 SMBus: Intel Corporation 82801BA/BAM SMBus (rev 12) 00:1f.4 USB Controller: Intel Corporation 82801BA/BAM USB (Hub #2) (rev 12) 00:1f.5 Multimedia audio controller: Intel Corporation 82801BA/BAM AC'97 Audio (rev 12) 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) 01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (Secondary) (rev 01) 02:08.0 Ethernet controller: Intel Corporation 82801BA/BAM/CA/CAM Ethernet Controller (rev 03) 02:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 02:0b.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 22) System uname: 2.6.15-gentoo-r4 i686 Intel(R) Pentium(R) 4 CPU 2.00GHz
Disabled RenderAccer and got two lockups in moebius very fast. Disabling dri now. It looks like xserver is not the right component although it does happen with the modular X server. Perhaps dri is for the driver bugs?
With dri disabled I get no lockups. Looks like a dri bug. Is there anything the X server produces that would make it clearer why it locks up?
(In reply to comment #2) > With dri disabled I get no lockups. > > Looks like a dri bug. > > Is there anything the X server produces that would make it clearer why it locks up? Not really. But there have been recent changes in CVS that address lockup problems on Radeons. You can try installing a binary snapshot on top of Xorg 7: http://dri.freedesktop.org/wiki/Download#head-55420c59a1c2e9a70f07a6fa02f0d228ffb87b76 Or build the radeon driver from CVS.
(In reply to comment #3) > Not really. But there have been recent changes in CVS that address lockup > problems on Radeons. You can try installing a binary snapshot on top of Xorg 7: > http://dri.freedesktop.org/wiki/Download#head-55420c59a1c2e9a70f07a6fa02f0d228ffb87b76 > Or build the radeon driver from CVS. The binary snapshots do not work for me, and as far as I can tell there are only build instructios for the dri cvs for use with the monolithic X server, not the modular one. Perhaps they will fix the snapshots eventually.
(In reply to comment #4) > > The binary snapshots do not work for me, and as far as I can tell there are only > build instructios for the dri cvs for use with the monolithic X server, not the > modular one. > > Perhaps they will fix the snapshots eventually. > Binary snapshots should work with modular Xorg. I fixed that about two weeks ago. If the snapshot installation is giving you trouble, please let me know, I am the maintainer. And last time I checked someone updated the build instructions for modular Xorg as well.
With the new 20060322 driver and the 1.0.2 server X still locks up.
Testing with 7.1 and Radeon 9250 (rv280) results in the other bug about X crashing without DRI. 7.1 with Radeon 9100 (r200) still locks up for me. ii libdrm2 2.0.2+git20060809-0ubuntu1 Userspace interface to kernel DRM services - ii libgl1-mesa-dri 6.5.1~20060817-0ubuntu2 A free implementation of the OpenGL API -- D ii libgl1-mesa-glx 6.5.1~20060817-0ubuntu2 A free implementation of the OpenGL API -- G ii xserver-xorg-core 1.1.1-0ubuntu11 X.Org X server -- core server ii xserver-xorg-video-ati 6.6.2-0ubuntu2 X.Org X server -- ATI display driver The lockup can be quickly reproduced by running StepMania - I haven't seen this run for more than a few minutes. The same could be probably achieved by some of the xscreensaver GL hacks. I had to disable xscreensaver to prevent computer lockups. The symptoms are always the same: the X server locks up, the picture on the monitor remains unchanged until reboot. The X applications keep running, and at least some still preform functions that do not require the X server.
(In reply to comment #7) > > 7.1 with Radeon 9100 (r200) still locks up for me. Can you try Mesa CVS (or at least the final 6.5.1 release) and possibly DRM and xf86-video-ati git?
Linux 2.6.18, DRM git, Mesa cvs, and ati driver git: 1st try: glxgears very slow, StepMania produces black screen only (hard reboot) 2nd try: Xorg.0.log says DRI initialized fine but produces lots of warning about visuals unsupported by dri driver. glxinfo says rendering is indirect glxgears locks up X even before it's window is shown. It looks like the same thing as previosly - I can normally shut down the machine using the power button (acpid), the picture displayed on the screen does not change until poweroff.
I tried again with drm/mesa/ati as of monday/tuesday. I could run an OpenGL application for a few hours which is certainly an improvement in stability over the versions that crashed within minutes. This is good enough for games. However, I would have to test for much longer to see if the original problem is solved - if the driver is stable enough for desktop use.
With xorg 7.2 rc3 and mesa git I got a lockup in one of the hyper- (hyperball?) xscreensacer hacks. This one locked up the machine completely, I could not log in over network. It took about a day to lock up but running that hack from the start would probably give faster result. I am using 2.6.17 kernel and libdrm 2.3.0. (II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.24.0 There are lots of (EE) RADEON(0): GetBuffer timed out, resetting engine... (**) RADEON(0): EngineRestore (32/32) at the end of the log but I have no idea if that is related since there are no timestamps.
Both hypercube and hyperball use only lines, so it sounds like there's an issue with line acceleration. Can you try disabling it with Option "XaaNoSolidBresenhamLine" Option "XaaNoSolidTwoPointLine" (check the log file for which one(s) of these disable line acceleration) to verify this?
Also, does this only happen with the DRI enabled, or also with it disabled? Please also attach the full X log file. This was also reported to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301531, also with a Radeon 9200. Roland, can you reproduce this with your RV280 card?
Without DRI the system appears pretty stable, I could run for more than a week without problems. With DRI and the options disabling line acceleration the line drawing is _very_ slow (probably even slower than without DRI but with line accel). The visual glitches are gone, only the hyperball is dispalyed, no leftover line segments are present. I could run hyperball for a few days continuosly without lockups.
Created attachment 8533 [details] Xorg log Fresh Xorg log. I did not save the log of the crashed server.
The Debian bug report now has a patch (a workaround) for this. Please test if it fixes the issue for you.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
It looks like the patch does the same as the options. Turns off line acceleration that causes the lockups.
I guess this is fixed. The fact that line acceleration does not in fact work is not important from this point of view. Was the workaround checked into xorg?
(In reply to comment #19) > Was the workaround checked into xorg? Yes.
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.