Solaris 10 x86 + Sun patch 118966-03 (= Xorg 6.8.2)
Almost any qt-x11-beta-4.0.0-b2 sample program
(examples/dialog/complexwizard, or examples/itemviews/dirview) crashes
the Xorg 6.8.2 server (or the whole machine?), on a Radeon 7500 AGP
display device installed in a dual amd box.
The machine appears to be locked up, and needs to be reset.
The qt4 library was configured to use most X.org server extensions
available with Solaris 10 (RandR, Render, Xft, Freetype, ...), using
configure -I/usr/X11/include -I/usr/sfw/include \
-L/usr/X11/lib -L/usr/sfw/lib \
truss -w2 -p `pgrep Xorg` reveals error messages like this:
(EE) RADEON(0): FIFO timed out, resetting engine...\n
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().
#0 0xce3350b0 in R100SubsequentCPUToScreenTextureMMIO () from
#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
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>
(RadeonGetTextureFormat), (F_TO_DW), (ATILog2),
(RADEONInit3DEngineForRender), (RemoveLinear), (RenderCallback),
(AllocateLinear), (RadeonInit3DEngine), (R100SetupTexture),
- 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,
VendorName "ATI Technologies Inc"
BoardName "Radeon RV200 QW [Radeon 7500]"
Option "RenderAccel" "False"
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
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
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
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
Xorg 6.8.x radeon driver in Solaris to misbehave.