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
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
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
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
01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO]
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
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:
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:
> 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
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
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
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
Linux 2.6.18, DRM git, Mesa cvs, and ati driver git:
1st try: glxgears very slow, StepMania produces black screen only
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
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
Both hypercube and hyperball use only lines, so it sounds like there's an issue
with line acceleration. Can you try disabling it with
(check the log file for which one(s) of these disable line acceleration) to
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]
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?