Red Hat Bugzilla – Bug 180150
Red Hat RV100 bus master patch breaks DRI on Radeon 7200 (R100 QD)
Last modified: 2007-11-30 17:11:23 EST
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 18.104.22.168" 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-22.214.171.124-2". The graphics card
is a "PCI" model, not an "AGP" one.
Version-Release number of selected component (if applicable):
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
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
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
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:
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
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
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
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
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:
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  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:
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:
I have rebuilt "xorg-x11-6.8.2-37.FC4.49.2" taking into account the
modifications suggested by M. DÃ¤nzer at:
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
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
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-126.96.36.199-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-188.8.131.52-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 ?