Bug 143398 - r128 DRI fails to start on iBook2
r128 DRI fails to start on iBook2
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2004-12-20 07:33 EST by Ralf Ertzinger
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-07 20:59:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Working xorg.conf (2.80 KB, text/plain)
2004-12-20 07:34 EST, Ralf Ertzinger
no flags Details
Failing xorg.conf (2.80 KB, text/plain)
2004-12-20 07:35 EST, Ralf Ertzinger
no flags Details
Working Xorg.0.log (29.95 KB, text/plain)
2004-12-20 07:35 EST, Ralf Ertzinger
no flags Details
Failing Xorg.0.log (28.29 KB, text/plain)
2004-12-20 07:35 EST, Ralf Ertzinger
no flags Details

  None (edit)
Description Ralf Ertzinger 2004-12-20 07:33:56 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):

How reproducible:

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

Additional info:
Comment 1 Ralf Ertzinger 2004-12-20 07:34:41 EST
Created attachment 108889 [details]
Working xorg.conf
Comment 2 Ralf Ertzinger 2004-12-20 07:35:07 EST
Created attachment 108890 [details]
Failing xorg.conf
Comment 3 Ralf Ertzinger 2004-12-20 07:35:29 EST
Created attachment 108891 [details]
Working Xorg.0.log
Comment 4 Ralf Ertzinger 2004-12-20 07:35:47 EST
Created attachment 108892 [details]
Failing Xorg.0.log
Comment 5 Mike A. Harris 2005-01-17 07:26:03 EST
Thanks for your report.  Please upgrade to the latest xorg-x11 build
( 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
xorg@freedesktop.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.

Thanks again.
Comment 6 Mike A. Harris 2005-01-17 07:32:32 EST
I missed this the first time:

> Btw: I could not find a -debuginfo package for xorg. Is this 
> intentional?

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)
Comment 7 Ralf Ertzinger 2005-01-17 12:19:22 EST
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.
Comment 8 Ralf Ertzinger 2005-01-27 07:26:42 EST
Just for info, the latest rawhide (xorg-x11- 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).
Comment 9 Mike A. Harris 2005-01-27 07:56:16 EST
Are you saying this problem is now resolved in rawhide?
Comment 10 Ralf Ertzinger 2005-01-27 08:00:41 EST
The R128 driver still fails to load with 'Option "UseFBDev" "false"',
but DRI works.

So, this can be closed, kind of.
Comment 11 Mike A. Harris 2005-02-01 05:13:06 EST
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
Comment 12 Mike A. Harris 2005-02-01 05:26:44 EST
Setting status to "NEEDINFO", awaiting upstream bug report URL.
Comment 13 Ralf Ertzinger 2005-02-02 07:54:35 EST
There is a tracking bug for this already in xorg, and a proposed patch:

Comment 14 Mike A. Harris 2005-02-07 20:59:06 EST
Ok, thanks for the Xorg bug URL.  We'll track the issue in the
upstream bugzilla now.

Setting status to "UPSTREAM".

Note You need to log in before you can comment on or make changes to this bug.