Red Hat Bugzilla – Bug 143398
r128 DRI fails to start on iBook2
Last modified: 2007-11-30 17:10:57 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041216 Firefox/1.0 Fedora/1.0-6
Description of problem:
The r128 driver works fine when used with 'Option "UseFBDev" "true"'
Disabling this line ought to enable DRI usage (which is loaded), but
starting the X server fails with a not too clear error message:
Fatal server error:
Caught signal 7. Server aborting
Working and failing configs/Xorg.0.log are attached.
Btw: I could not find a -debuginfo package for xorg. Is this intentional?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Disable framebuffer usage for r128 driver on ppc
2. restart X
Actual Results: X server fails to start
Expected Results: X server starts
Created attachment 108889 [details]
Created attachment 108890 [details]
Created attachment 108891 [details]
Created attachment 108892 [details]
Thanks for your report. Please upgrade to the latest xorg-x11 build
(22.214.171.1242-1 currently) and the latest kernel, and if the SIGBUS
problem still exists, you can report the problem to X.Org via the
X.Org bugzilla located at: http://bugs.freedesktop.org in the "xorg"
component, and X.Org developers maintaining DRI on Radeon on PPC will
investigate the issue. It is also highly recommended to join the
firstname.lastname@example.org mailing list and discuss the issue there as
well, and summarize any findings in your X.Org bug report.
Once your bug report has been filed, please paste the URL here, and
we will track the X.Org bug report and review any bug fixes that
become available for potential inclusion in future rpm builds.
I missed this the first time:
> Btw: I could not find a -debuginfo package for xorg. Is this
Yes, rpm's default stripping policy strips too much stuff from
the X server modules, causing the X server to reject loading
them. As such, the xorg-x11 rpm spec file manually strips
everything in a way that is safe. In order to create debuginfo
packages, we'd have to reimplement the debuginfo shell scripting
contained in rpm inside the X spec file, which is a bit ugly.
That is complicated by the fact the debuginfo generation code
has changed from OS release to release in incompatible ways, which
would mean we'd have to implement debuginfo stripping per-OS
in the specfile which would be a mess.
On a final note, the modular X server is not debuggable using
standard gdb, even if everything is unstripped, so debuginfo
rpm would only be useful for the libs and clients, but not for
the core X server.
There are several X.Org upstream changes that are coming in the
future, which will make it possible to do all of this in a
future OS release in 12-24 months or so however. I'm looking
forward to that. ;o)
This seems to be a known problem (sorry, I should have looked in the
xorg bugzilla first).
Tracking bug (including a test patch) for this is
I'm willing to try if this makes any difference.
Just for info, the latest rawhide (xorg-x11-126.96.36.1992-4) has magically
enabled DRI, although I am still running 'Option "UseFBDev" "true"'. I
do not know if not going though the framebuffer would result in faster
output, but basic accelerated 3D works (bzflag works, celestia works
with minor glitches).
Are you saying this problem is now resolved in rawhide?
The R128 driver still fails to load with 'Option "UseFBDev" "false"',
but DRI works.
So, this can be closed, kind of.
Ok, please report the remaining issue in the X.Org bugzilla at
http://bugs.freedesktop.org in the "xorg" component, so ppc
X developers are aware of the issue. Once you've filed your
report upstream, paste the bug URL here, and Red Hat will
track the issue in the X.Org bug tracker, and review any
fixes that become available for consideration in future FC
Setting status to "NEEDINFO", awaiting upstream bug report URL.
There is a tracking bug for this already in xorg, and a proposed patch:
Ok, thanks for the Xorg bug URL. We'll track the issue in the
upstream bugzilla now.
Setting status to "UPSTREAM".