Bug 182196 - DRI on Radeon R300 (and later models) needs fixing before enabling.
DRI on Radeon R300 (and later models) needs fixing before enabling.
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
NeedsRetesting
:
: 174646 175263 177773 182720 183074 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-20 17:49 EST by cam
Modified: 2007-11-30 17:11 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-25 04:54:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
xorg log file (37.43 KB, text/plain)
2006-02-21 15:33 EST, cam
no flags Details
compressed tarfile containing matched pair of xorg.conf file and resulting log file, illustrating bug which is still present when Option "nodri" is used (7.83 KB, application/octet-stream)
2006-02-22 13:00 EST, cam
no flags Details
collection of xorg logs from scenarios with and without moved r300_dri, and nodri option (19.00 KB, application/octet-stream)
2006-02-23 16:41 EST, cam
no flags Details
xorg log after r300 dri module has been moved to /root (37.86 KB, text/plain)
2006-02-24 07:52 EST, cam
no flags Details
xorg log from hang when r300 moved to /root and nodri option used (34.19 KB, text/plain)
2006-02-24 07:53 EST, cam
no flags Details
xorg log with option nodri (34.23 KB, text/plain)
2006-02-24 07:54 EST, cam
no flags Details
Xorg.log of successful start of X after radeon.ko moved aside (38.33 KB, text/plain)
2006-03-05 04:59 EST, cam
no flags Details

  None (edit)
Description cam 2006-02-20 17:49:29 EST
Description of problem:

Installed FC5t2, X would hang the machine. Booted as single user and yum updated
as at 20th Feb 2006

A separate bug related to the synaptics driver and Signal 11 being caught (182194)
This bug relates to the X server hanging the machine.

xorg-x11-drivers-7.0-2
xorg-x11-drv-ati-6.5.7.3-3.2

Dell Inspiron 6000 with Radeon X300, synaptics touchpad and 1920x1200 screen

How reproducible: every time

Steps to Reproduce:
1. Install FC5t2, yum update. 
2. attempt to start X
  
Actual results:

X server hangs machine requiring power off

Expected results:

X server starts normally

Workaround: remove or comment the following line from xorg.conf:

#       Load  "dri"
Comment 1 Mike A. Harris 2006-02-21 06:13:48 EST
Uncomment the Load "dri" line, and try the following line in the device
section instead:

    Option "nodri"

Does that work around the issue as well?  Please respond as soon as possible,
as there is limited time left to resolve bugs for FC5 final.

Thanks in advance.
Comment 2 cam 2006-02-21 15:31:31 EST
Mike I tried your workaround but I regret it wasn't effective. With your
workaround in place the server hung the machine again, and on rebooting the log
contained the following:

(II) RADEON(0): Detected Radeon Mobility X300, disabling multimedia i2c
(II) Loading sub module "theatre_detect"
(II) LoadModule: "theatre_detect"

I will attach the full log.
Comment 3 cam 2006-02-21 15:33:00 EST
Created attachment 124981 [details]
xorg log file
Comment 4 Mike A. Harris 2006-02-22 03:09:14 EST
The full log that is attached, appears to be from the "dri is enabled"
configuration.  Please attach the log from when using:

    Option "nodri"

in the device section.


If commenting out 'Load "dri"' resolves the issue, but Option "nodri" does
not resolve the issue, then we are in a bit of a bind.  I really hoped we
could ship the r300 DRI driver but have it disabled by default, by having
the 2D driver default to "nodri" on those cards.  However, if that does not
work, we're most likely going to have to disable r300 DRI at compile time
too, as it's just not turning out to be very stable/reliable for people
even just for experimentation.  ;o/

Please let me know ASAP.  Hopefully we can figure something out.
Comment 5 cam 2006-02-22 12:59:06 EST
Apoligies for the confusion. I have done some more tests and after the machine
hangs the log doesn't always get written (or is lost when the FS is recovered on
subsequent boot).

I have attached a log that is definitely from a run with Load "dri" and Driver
Option "nodri". The bug is still present.

Is it better to comment out 'Load "dri"' and leave room for experimentation
rather than disable it in software?
Comment 6 cam 2006-02-22 13:00:46 EST
Created attachment 125047 [details]
compressed tarfile containing matched pair of xorg.conf file and resulting log file, illustrating bug which is still present when Option "nodri" is used
Comment 7 cam 2006-02-22 18:45:34 EST
Have reproduced the same problem with FC5t3. Commenting out Load "dri" works;
adding Options "nodri" doesn't. Will try xorg-x11-drv-ati-6.5.7.3-4
Comment 8 Mike A. Harris 2006-02-22 20:15:04 EST
Do you have ATI's proprietary fglrx driver installed by chance, or have you
ever had it installed?  Reason I ask, is that a number of DRI related bugs
being reported are turning out to be caused due either to fglrx being
installed, or due to it being installed at one point and uninstalled, and
the ATI uninstall process destroying Fedora's libGL when it uninstalls.

If you could confirm this either way, it'd be useful info to hopefully
rule out fglrx as a catalyst.

Assuming we can rule out fglrx, can you try temporarily moving the r300
DRI driver out of the way and trying to start X with Load "dri" present?

/usr/lib/dri/r300*  try moving it to /root temporarily

After starting the X server, the DRI extension module should load, but
DRI support for r300 should _not_ load.  If you could attach your X
server log from that, it'd be useful to see as well.  I have a feeling
that the kernel DRM module is being loaded even when dri is disabled,
and that the r300 kernel code might be hanging your system perhaps.

I've got a Radeon 9800Pro here which I'm trying to reproduce this on,
but I'm having a totally separate problem with it currently I'm trying
to iron out.  I can get the X server to start in some cases however,
and my problems don't appear to be caused by DRI.

Attach your log and we'll go from there.

Thanks in advance.
Comment 9 cam 2006-02-23 16:12:37 EST
We can definitely rule out fglrx here. I have installed fc5t2 and fc5t3,
formatting / on the way. The last time I used fglrx was in the fc4 days.

As an aside for your Radeon 9800Pro have you tried Driver Option "AGPMode" "8"?

I'll attach a log from the 'moved r300_dri' scenario in a bit,
Comment 10 cam 2006-02-23 16:41:10 EST
Created attachment 125139 [details]
collection of xorg logs from scenarios with and without moved r300_dri, and nodri option

It seems that if the x server attempts to load dri, it hangs no matter what
else we do?
Comment 11 Mike A. Harris 2006-02-24 06:46:56 EST
Please attach files as individual uncompressed browser-readable files.
Comment 12 cam 2006-02-24 07:52:11 EST
Created attachment 125172 [details]
xorg log after r300 dri module has been moved to /root
Comment 13 cam 2006-02-24 07:53:04 EST
Created attachment 125173 [details]
xorg log from hang when r300 moved to /root and nodri option used
Comment 14 cam 2006-02-24 07:54:04 EST
Created attachment 125174 [details]
xorg log with option nodri
Comment 15 Mike A. Harris 2006-02-28 13:04:21 EST
can you do another test, and move the "radeon" kernel module to /root
temporarily too, and do a full reboot, and try again.  I'd like to see
if it is the kernel module loading which is causing the problem.

Still can't reproduce locally. ;/
Comment 16 cam 2006-03-05 04:57:46 EST
Re comment #15,

I'm now running 2.6.15-1.2009.4.2_FC5

I rebooted, starting in run level 3 and verified that the modules weren't
loaded. xorg.conf had 'Load "dri"' The dri and radeon modules were moved to
/root. init 5 started X without problems. 

The Xorg.0.log shows a message about failing to load radeon just after the point
where it usually crashes. So it seems like it may be the radeon.ko module
loading that causes problems.

Xorg.log attached for interest.
Comment 17 cam 2006-03-05 04:59:55 EST
Created attachment 125664 [details]
Xorg.log of successful start of X after radeon.ko moved aside
Comment 18 Mike A. Harris 2006-03-05 19:24:35 EST
Ok, so it looks like the radeon.ko kernel module is what is causing the system
to lock up.

Since r300 DRI support is experimental/unstable at this point in time, and we
do not ship the userland r300 DRI driver, we should probably disable R300
kernel DRM support for now also.

Dave, can you disable r300 support in the radeon DRM?
Comment 19 Dave Jones 2006-03-05 23:32:17 EST
That's a lot of IDs :)
Just to be sure..  (I take it you want RV350 chopped out too..)

        {0x1002, 0x4144, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R300}, \
        {0x1002, 0x4145, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R300}, \
        {0x1002, 0x4146, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R300}, \
        {0x1002, 0x4147, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R300}, \
        {0x1002, 0x4E44, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R300}, \
        {0x1002, 0x4E45, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R300}, \
        {0x1002, 0x4E47, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R300}, \
        {0x1002, 0x4E48, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R350}, \
        {0x1002, 0x4E49, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R350}, \
        {0x1002, 0x4E4B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R350}, \
        {0x1002, 0x554F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R350}, \
        {0x1002, 0x5d4d, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R350}, \

        {0x1002, 0x3150, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV350},\
        {0x1002, 0x4150, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV350}, \
        {0x1002, 0x4151, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV350}, \
        {0x1002, 0x4152, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV350}, \
        {0x1002, 0x4153, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV350}, \
        {0x1002, 0x4154, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV350}, \
        {0x1002, 0x4156, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV350}, \
        {0x1002, 0x4E46, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV350}, \
        {0x1002, 0x4E4A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV350}, \
        {0x1002, 0x4E50, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV350|CHIP_IS_MOBILITY}, \
        {0x1002, 0x4E51, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV350|CHIP_IS_MOBILITY}, \
        {0x1002, 0x4E54, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV350|CHIP_IS_MOBILITY}, \
        {0x1002, 0x4E56, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV350|CHIP_IS_MOBILITY}, \
        {0x1002, 0x5460, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV350}, \


Chop all those ?
Comment 20 Dave Jones 2006-03-05 23:47:00 EST
(And I asssume R420 & RS3xx ?)
Comment 21 Mike A. Harris 2006-03-06 15:48:30 EST
Yeah, anything R300 or higher, including RS/RV 3xx, 4xx, etc.
Comment 22 Mike A. Harris 2006-03-06 17:36:05 EST
*** Bug 183074 has been marked as a duplicate of this bug. ***
Comment 23 Mike A. Harris 2006-03-06 17:39:33 EST
*** Bug 177773 has been marked as a duplicate of this bug. ***
Comment 24 Dave Jones 2006-03-06 18:11:49 EST
ID's removed in latest build.
I'll leave this bug open, as eventually we'll want this to work, so I'll
optimistically reenable them in FC6 hoping that things improve.

Comment 25 Dave Jones 2006-03-06 18:12:34 EST
*** Bug 174646 has been marked as a duplicate of this bug. ***
Comment 26 Hans de Goede 2006-03-07 02:54:51 EST
Since according to comment 24 this seems fixed for now, I think this can be
removed from the FC5 blocker list, correct?
Comment 27 Mike A. Harris 2006-03-07 04:29:12 EST
Yes, switched to FC6Target
Comment 28 Mike A. Harris 2006-03-07 07:30:20 EST
*** Bug 182720 has been marked as a duplicate of this bug. ***
Comment 29 Pawel Salek 2006-03-07 17:21:57 EST
The reporter's card is connected via the PCIE interface - I think it's the
interface that is the culprit. I have never seen any problems with these few AGP
R3xx cards I have used but I did see problems with PCIE-type cards.
Comment 30 Mike A. Harris 2006-03-10 19:38:53 EST
*** Bug 175263 has been marked as a duplicate of this bug. ***
Comment 31 WangKeMeng 2006-03-14 22:34:32 EST
Not only DRI hang the machine, see bug #183978, so simple disable DRI is not a
good idea, It seems a bug in radeon kernel driver or PCIE drivers, not the
DRI.Why do not ship DRI?, do not ship radeon kernel driver is better. After
start X, run kudzu or firstboot or system-config-display, all of them hang the
machine.
Comment 32 Dave Jones 2006-03-17 15:21:45 EST
the radeon driver does actually work on the lower end chips, so not shipping it
would break currently working systems on upgrade.

With the broken chip IDs disabled in the driver, it should never get loaded on
your system.

If it's still crashing without that driver loaded, it's an X server bug.
Comment 33 Jerry James 2006-03-26 18:52:21 EST
I am hitting what appears to be this bug, but on one of the lower end chips
where it is supposed to work.  I have a Radeon RV100 QY (Radeon 7000/VE).  I
just installed FC5 on the machine.  This is a new install, not an upgrade.  I
can boot up, and gdm appears fine.  Upon logging in, though, the entire system
freezes up within a few seconds.  On several of my login attempts, the desktop
didn't finish drawing itself.  This is a hard freeze; the system doesn't respond
to pings.  Upon searching bugzilla and finding this bug, I tried commenting out
'Load "dri"' as suggested.  I am typing this message on that machine, where I
have been logged in successfully for over 15 minutes now.

I can provide the X server log and xorg.conf if you want, but xorg.conf is the
default one created at install time and the log shows nothing unusual.
Comment 34 David Lawrence 2006-04-18 16:12:39 EDT
NEEDINFO_ENG has been deprecated in favor of NEEDINFO or ASSIGNED. Changing
status to ASSIGNED for ENG review.
Comment 35 Dave Jones 2006-10-16 16:28:09 EDT
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.
Comment 36 Ray Rees 2006-11-15 12:20:15 EST
FC6 appears to exhibit same issue. Frequent lockups are occurring on my ThinkPad
T30. See bug#213227.
Could someone please provide a step by step workaround guide for fixing this
issue? I would really like to migrate to FC6, but this bug is making me think twice.
Please help...
Thanks!
Comment 37 Ray Rees 2006-11-16 13:24:18 EST
ATI Mobility Radeon 7500 lock up bug supposedly fixed in Ubuntu:
https://launchpad.net/distros/ubuntu/+source/xserver-xorg-video-ati/+bug/47775/comments/53

When will this driver be available for FC6?
Comment 38 Dave Jones 2006-11-20 20:22:19 EST
The kernel side of this should be pretty current, but the X drivers may need
updating in FC5 to take advantage of this.

Reassigning in hope that someone has more clue than me as to their status..
Comment 39 Matěj Cepl 2007-06-20 17:34:14 EDT
Since this bugzilla report was filed, there have been several major updates,
which may have resolved this issue. Users who have experienced this problem are
encouraged to upgrade their system to the latest version of their distribution
available.

Please, if you experience this problem on the up-to-date system, let us now in
the comment for this bug, or whether the upgraded system works for you.
Comment 40 darrell pfeifer 2007-06-22 09:23:51 EDT
On FC8 rawhide, glxgears and compiz are working correctly on my R300 machine.
Comment 41 Matěj Cepl 2007-06-25 04:54:14 EDT
Thanks a lot, closing as RAWHIDE.
Comment 42 redhat-bugs2eran 2007-06-26 21:02:14 EDT
I'm still getting system hangs when running 3D apps (e.g., tuxsaver and
google-earth) with DRI is enabled, on Fedora 7 plus
xorg-x11-server-Xorg-1.3.0.0-10.fc8 and xorg-x11-drv-ati-6.6.3-4.fc8.

Is there any other relevant RPM? If not, the bug is unresolved.

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