Bug 5986

Summary: [radeon] The X server locks up after a few days. Radeon 9200.
Product: xorg Reporter: Michal Suchanek <hramrach>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: high CC: glisse, npeninguy, sroland
Version: git   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg log none

Description Michal Suchanek 2006-02-21 20:44:51 UTC 
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
Comment 1 Michal Suchanek 2006-02-24 02:24:50 UTC 
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?
Comment 2 Michal Suchanek 2006-03-22 00:32:26 UTC 
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?
Comment 3 Felix Kühling 2006-03-22 01:03:24 UTC 
(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.
Comment 4 Michal Suchanek 2006-03-24 00:54:01 UTC 
(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.
Comment 5 Felix Kühling 2006-03-24 01:11:13 UTC 
(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.
Comment 6 Michal Suchanek 2006-03-27 18:21:07 UTC 
With the new 20060322 driver and the 1.0.2 server X still locks up.
Comment 7 Michal Suchanek 2006-10-01 14:03:37 UTC 
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.
Comment 8 Michel Dänzer 2006-10-02 02:13:34 UTC 
(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?
Comment 9 Michal Suchanek 2006-10-08 05:37:39 UTC 
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.
Comment 10 Michal Suchanek 2006-11-30 14:46:07 UTC 
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.
Comment 11 Michal Suchanek 2007-01-12 10:34:21 UTC 
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.
Comment 12 Michel Dänzer 2007-01-12 11:58:18 UTC 
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?
Comment 13 Michel Dänzer 2007-01-17 02:38:27 UTC 
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?
Comment 14 Michal Suchanek 2007-01-29 04:21:28 UTC 
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.
Comment 15 Michal Suchanek 2007-01-29 04:24:47 UTC 
Created attachment 8533 [details]
Xorg log

Fresh Xorg log. I did not save the log of the crashed server.
Comment 16 Timo Jyrinki 2007-02-25 04:31:30 UTC 
The Debian bug report now has a patch (a workaround) for this. Please test if it fixes the issue for you.
Comment 17 Daniel Stone 2007-02-27 01:30:34 UTC 
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 18 Michal Suchanek 2007-03-19 12:12:03 UTC 
It looks like the patch does the same as the options. Turns off line acceleration that causes the lockups.
Comment 19 Michal Suchanek 2007-09-18 03:19:04 UTC 
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?
Comment 20 Michel Dänzer 2007-09-18 04:07:29 UTC 
(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.