From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051125 Fedora/1.7.12-1.2.1.legacy Description of problem: Since the days of "Xorg 6.8.99.14" until today it has been impossible for me to use hardware rendering on my "PR440FX" SMP box which uses a "Radeon 7200" (R100QD) based "Radeon All-in-Wonder" graphics card. This also applies to "xorg-x11-drv-ati-6.5.7.3-2". The graphics card is a "PCI" model, not an "AGP" one. Version-Release number of selected component (if applicable): xorg-x11-drv-ati-6.5.7.3-2 How reproducible: Always Steps to Reproduce: 1. Enable "DRI" in "/etc/X11/xorg.conf". 2. Boot "FC5/Rawhide". Actual Results: The boot-up procedure proceeds normally including "rhgb" until the final "X" server and "gdm" are supposed to be launched. The server tries to execute. Then, the monitor turns black and goes to standby mode. The computer does not react to the keyboard. Expected Results: One should be granted with a graphical login screen and working hardware rendering. Additional info: Launching the "X" server by means of "startx" from run level 3 does not help either. Disabling "DRI" allows to start the "X" server as expected. Hardware rendering was working properly for earlier releases. For the SMP-kernel, starting the "X" server always fails with expection of the one and only session directly after leaving the "firstboot" panel. Direct rendering is enabled and working then and only then but fails after any subsequent boot! This also happens for the uniprocessor kernel. Unfortunately, I cannot check if it is still possible to login over the network. In contrast with similar bug reports, the current bug affects a fairly old ATI chip which has been around for many years. Finally, hardware rendering works normally for a uni-processor kernel based "Ubuntu 6.04-current" live CD that also uses modular "X".
Unfortunately PCI Radeon support is nowhere near as stable and reliable as AGP Radeon support, mostly due to the fact that barely any X.Org developers have any PCI Radeon hardware, and it gets very very little testing by anyone. ;o( We can try to help you diagnose the problem, but keep in mind we do not have the actual hardware to diagnose the issue directly. If the problem can't be isolated this way, we can tweak the driver to disable DRI by default on Radeon 7200 PCI, similar to how Radeon 7000 DRI is disabled by default in FC4. That would make a more stable system by default at least until upstream X developers can resolve the underlying issue. Lets start by getting your X server config file and log file as individual uncompressed file attachments, and a copy of your /var/log/messages. Please indicate what versions of "mesa", "libdrm", "xorg-x11-server-Xorg" are installed also, and what specific kernel rpms are being used. Thanks in advance.
I have compared the "xorg.conf" file generated by the already mentioned "Ubuntu 6.04-current"live CD with the "pyxf86config" generated one, and it turns out that there is a crucial difference between the two. The "Ubunutu" one has an additional entry: BusID "PCI:0:11:0" in the "Device" section. This agrees with the data reported by "lscpi" where the following entry appears: "00:0b.0 VGA compatible controller: ATI Technologies Inc Radeon R100 QD [Radeon 7200]" Adding the bus ID line to the original "xorg.conf" file generated by "pyxf86config", the system boots into graphical mode as expected, and hardware rendering is enabled and functional. Bug needs probably to be reassigned to "pyxf86config-0.3.22" or "kudzu-1.2.24-1".
Created attachment 124335 [details] Output of "lspci -vv" for Radeon R100 QD [Radeon 7200]
Unfortunately, my conclusions seem to have been a bit premature. After a dozen of "X" shutdown/start cycles, I have the same problem as before even when the bus ID is specified. I have now reinstalled FC4, and here, everything works a expected. I will compare "Xorg" version 6.8.2 with the situation after installing my own 6.9 RPMs. I will finally give FC5 test3 a shot once it has been released. Anyway, disabling "DRI" by default seems too drastic a measure to take. Hardware rendering with Fedora used to work flawlessly since summer 2004. Thus, the current issue is a mere regression. I will attach the relevant log files after having investigated somewhat further. Thanks!
Direct rendering works well on a stock FC4 install as stated above. However, after installing all currently available updates, "X" hangs when the graphical login screen is about to be displayed. The issue thus appeared for some Fedora update of "Xorg" 6.8.2. Result: xorg-x11-6.8.2-31 [+] works xorg-x11-6.8.2-37.FC4.49.2 [-] hangs Downgrading to "xorg-x11-6.8.2-31" while keeping all other updates as of 2006/02/08 allows to recover a working system including functional hardware rendering. I will try to find some of the intermediate releases but by merely looking at the changelog it becomes apparent that quite a bit of tweaking of the "ati/radeon" driver for "Xorg" version 6.8.2 happened. Even if this bug report now rather refers to FC4 (related to Bug #168752 (?)), the issue is of course still also present in "FC5-Rawhide".
Created attachment 124406 [details] "xorg.conf" for Radeon 7200 [R100 QD]
Created attachment 124407 [details] Xorg.0.log for release 6.8.2-37.FC4.49.2
Created attachment 124408 [details] dmesg log file for 2.6.15-1.1831_FC4smp and -old- xorg-x11-6.8.2-31 No "dmesg" file was created for xorg-x11-6.8.2-37.FC4.49.2 before the system got stuck.
Created attachment 124409 [details] Excerpt from /var/log/messages for 2.6.15-1.1831_FC4smp and xorg-x11-6.8.2-37.FC4.49.2
Created attachment 124411 [details] dmesg log file for 2.6.15-1.1831_FC4smp and -old- xorg-x11-6.8.2-31
Focusing on the Radeon patch changes between "xorg-x11-6.8.2-31" and "xorg-6.8.2-37.FC4.49.2" and rebuilding the "X" packages for various combinations, the culprit for the lock-ups turns out to be: xorg-x11-6.8.1-ati-radeon-RV100-bus-master-fix.patch After disabling this and only this patch, rebuilding and installing the modified "X" packages, the "X" server starts up as expected. No other patch got modified or dropped. I recall that my graphics card is based on the original Radeon [7200] chip with ATI naming R100 QD. The graphical login panel becomes available and after logging in, direct rendering is up and running. Another possibly related issue is that the frame rate of "glxgears" is a mere 130 FPS on Fedora whereas I achieve about 350 FPS with alternative Linux distributions featuring the same "X" version 6.8.2.
The issue is under investigation upstream, as the patch seems to have been included to "Xorg" 6.8.99.x and 7.0.0 which explains my trouble with the modular server. A patch for the monolithic tree has been made available at: https://bugs.freedesktop.org/show_bug.cgi?id=5916 A backport to "Xorg" release 6.8.2 appears to be straightforward according to its author M. Dänzer.
This one also refers to the problem with disabling bus master support for Radeon cards with PCI interface: https://bugs.freedesktop.org/show_bug.cgi?id=4324
I have rebuilt "xorg-x11-6.8.2-37.FC4.49.2" taking into account the modifications suggested by M. Dänzer at: https://bugs.freedesktop.org/show_bug.cgi?id=4324 The packages build cleanly and after installing them, the system boots into graphical mode as expected. The whole with enabled "DRI"! This patch is a **must** for a future and really necessary update of "xorg-x11-6.8.2-37.FC4.49.2". I have also rebuilt my own "Xorg" 6.8.9 packages. Here, it also works. "glxgears" delivers about 360 FPS as it did for the last working release "xorg-x11-6.8.2-37.FC4.31". Of course, the issue needs also to be fixed in "xorg-x11-drv-ati" for which the bug had been posted in the first place.
After a clean install of "Fedora Core 5 test 3", it turned out that the issue is still present in "xorg-x11-drv-ati-6.5.7.3-3.2". Updating the driver from CVS and rebuilding the package allows to recover a working setup. The system boots into graphical mode as expected, and "DRI" is up and running according to "glxinfo". However, performance is low: only about 120 FPS for "glxgears". Setting "LIBGL_DEBUG" to "verbose" before executing "glxgears" does not reveal anything special.
Fixed in "xorg-x11-drv-ati-6.5.7.3-4" on FC5 (rawhide) for which I had posted the bug report in the first place. 3D performance is back to standard values (360 fps at 24 bpp for "glxgears") for FC5 final. However, FC4 is still affected by the bug, but M. Dänzer's patch is easily ported to Xorg 6.8.2 and gives has the desired effect. Please mark this for a service update to xorg-x11-6.8.2-37.FC4.49.2.
Yeah, the busmaster patch was a backport from upstream to work around another bug. We've integrated Michel's new patch into RHEL4 and disabled the busmaster patch. It'll be getting some testing during RHEL4U4 development cycle (right now). I've added this bug to the FC4Update tracker. It will probably get added to a future update. I'd like to sync a whackload of bug fixes from RHEL to Fedora 4, as they're fairly out of sync right now. Not sure exactly when that will happen though, but it'll happen. ;)
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.