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"
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.
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.
Created attachment 124981 [details] xorg log file
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.
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?
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
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
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.
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,
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?
Please attach files as individual uncompressed browser-readable files.
Created attachment 125172 [details] xorg log after r300 dri module has been moved to /root
Created attachment 125173 [details] xorg log from hang when r300 moved to /root and nodri option used
Created attachment 125174 [details] xorg log with option nodri
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. ;/
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.
Created attachment 125664 [details] Xorg.log of successful start of X after radeon.ko moved aside
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?
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 ?
(And I asssume R420 & RS3xx ?)
Yeah, anything R300 or higher, including RS/RV 3xx, 4xx, etc.
*** Bug 183074 has been marked as a duplicate of this bug. ***
*** Bug 177773 has been marked as a duplicate of this bug. ***
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.
*** Bug 174646 has been marked as a duplicate of this bug. ***
Since according to comment 24 this seems fixed for now, I think this can be removed from the FC5 blocker list, correct?
Yes, switched to FC6Target
*** Bug 182720 has been marked as a duplicate of this bug. ***
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.
*** Bug 175263 has been marked as a duplicate of this bug. ***
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.
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.
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.
NEEDINFO_ENG has been deprecated in favor of NEEDINFO or ASSIGNED. Changing status to ASSIGNED for ENG review.
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.
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!
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?
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..
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.
On FC8 rawhide, glxgears and compiz are working correctly on my R300 machine.
Thanks a lot, closing as RAWHIDE.
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.