Created attachment 2629 [details]
system call trace for Xorg server, immediatelly before it locks up

truss -w2 -p `pgrep Xorg`

After some debugging, I found out that the FIFO apparently locks up during a call
to ProcRenderComposite(), in a function R100SubsequentCPUToScreenTextureMMIO().

(gdb) bt
#0  0xce3350b0 in R100SubsequentCPUToScreenTextureMMIO () from
/usr/X11/lib/modules/drivers/radeon_drv.so
#1  0xce0da42f in XAADoComposite () from /usr/X11/lib/modules/libxaa.so
#2  0xce0da83f in XAAComposite () from /usr/X11/lib/modules/libxaa.so
#3  0x081884d3 in damageComposite ()
#4  0x0819c204 in CompositePicture ()
#5  0x0819db0b in ProcRenderComposite ()
#6  0x0819f929 in ProcRenderDispatch ()
#7  0x080cfc82 in Dispatch ()
#8  0x080e4291 in main ()


The bug appears to be a "known problem", Bug #748 added some new render
acceleration support which is only supported with DRI and is known to hang
MMIO.

    https://bugs.freedesktop.org/show_bug.cgi?id=748

Apparently the Radeon 7500 suffers from the MMIO hang introduced by the fix
for Bug #748.  Quote from the Xorg 6.8.2 ChangeLog file:


2004-06-19  Eric Anholt  <anholt@FreeBSD.org>

...

	* programs/Xserver/hw/xfree86/drivers/ati/radeon_render.c:
	(RadeonGetTextureFormat), (F_TO_DW), (ATILog2),
	(RADEONInit3DEngineForRender), (RemoveLinear), (RenderCallback),
	(AllocateLinear), (RadeonInit3DEngine), (R100SetupTexture),
	(R100SetupForCPUToScreenAlphaTexture),
	(R100SetupForCPUToScreenTexture),
	(R100SubsequentCPUToScreenTexture), (R200SetupTexture),
	(R200SetupForCPUToScreenAlphaTexture),
	(R200SetupForCPUToScreenTexture),
	(R200SubsequentCPUToScreenTexture):
	Bug #748:
	- Add Render acceleration for Radeon 100 and 200-series cards, enabled
	by default.  Notable performance gains include 27fps in cairogears
	instead of 6fps (compared to 50 with glitz), and my disks are now the
	bottleneck in an ls -lR in gnome-terminal.  Only supported in DRI mode
	because the MMIO submission hangs the card so far, but the code is left
	in because it may be supportable soon.



Workaround for the problem:
===========================


Add `` Option "RenderAccel" "False" '' to the Device ati section in xorg.conf,
like this:


Section "Device"
        Identifier  "Card0"
        Driver      "ati"
        VendorName  "ATI Technologies Inc"
        BoardName   "Radeon RV200 QW [Radeon 7500]"
        BusID       "PCI:1:5:0"
        Option      "RenderAccel"        "False"
EndSection

Are you still having this problem using a current version of xorg?

(In reply to comment #3)
> Are you still having this problem using a current version of xorg?

No, the problem seems to be fixed with the updated Xorg server from recent
Solaris Express releases.  I've installed the Xorg server from Solaris Express
snv_34 now, which announces itself as Xorg 6.9.0:

% more /var/log/Xorg.0.log

X Window System Version 6.9.0 (Sun Xorg Release 1.2 for Solaris 11)
Release Date: 21 December 2005
X Protocol Version 11, Revision 0, Release 6.9
Build Operating System: SunOS 5.11 snv_29 i86pc
Current Operating System: SunOS tiger2 5.11 wos_b39 i86pc
Build Date: 08 February 2006

...


I do not use "RenderAccel" "False" in xorg.conf any more, and the two
qt examples (now from QT 4.0.1) work just fine without locking up the
machine.



The relevant bug/fix from Sun's bug database might be bug 6339315,
"Bad compiler induces IBM Bladecenter HS20 resets on entry to GNOME with X.org
6.8.2"
<URL:http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6339315>

Unfortunatelly there's not much publicly visible information in that bug
report;  the synopsis seems to be a hint that the compiler (which one?)
miscompiled something in the ATI driver.

I'll see if I can fix the opensolaris.org bug report - short summary is that the
Studio 10 cc beta build originally used to build the Solaris 10 Xorg was not 
correctly honoring volatile keywords when dealing with some of the Radeon hardware
registers, and thus some of the OUT_ACCEL_REG calls were effectively optimized
out.   Upgrading to the final release of Studio 10 cc fixed this bug in the 
compiler.   (Solaris 10 was build with the beta release since Studio 10 &
Solaris 10 shipped at the same time, so Studio 10 final wasn't available in time
to build
Solaris 10.)

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6339315 now contains
an excruciating level of detail as to how the Studio 10 beta compiler was
causing the
Xorg 6.8.x radeon driver in Solaris to misbehave.