Description of problem:
XFree86 with RENDER has never worked properly on my machine, right from 4.0+,
through current 4.2.0 as shipped with RHL8. During heavy RENDER-related
activity, such as lots of scrolly gnome-terminals with mouse movement, the X
server just hangs. (The kernel and other processes usually continue to run.)
Some peculiarities with my setup:
- the machine has two r128 "All-In-Wonder 32 PCI" cards, and a motherboard i810e
- my normal X configuration is to have the two r128 PCI cards drive two
monitors, and the 810e part not being activated at all. This does not seem to
matter to the bug: one r128 with one 810e still produce hangs.
- I usually enable xinerama; the hangs occur with or without xinerama
- I played with lots of configuration parameters like XFree86 driver options.
No permutation proved stable with RHL 8.
The only parameter that seems constant is RENDER. With RHL 8, every dog & cat
uses it to plop text on the screen, so the hangs have occurred sometimes within
seconds, usually within minutes of regular X usage. I can't see an X server or
application configuration that turns off RENDER availability/use, so I was stuck.
I finally came up with a workaround: I disabled the RENDER extension in the
server by binary-editing the XFree86 executable, to rename RENDER -> RENDAR or
somesuch. Now clients don't find the extension, so don't try to use it. No
hangs have occurred since then.
So, if these r128 RENDER hangs prove too complex to solve outright, please add
an XFree86 option to disable RENDER by more palatable means.
Steps to Reproduce:
See above; I don't have a reproduction recipe. It may require multiple PCI r128
cards, and may or may not relate to an i810e motherboard.
I will attach my current xf86 config and log files, and lspci.
Created attachment 87227 [details]
Created attachment 87228 [details]
Created attachment 87229 [details]
lspci -v output
Here is an additional data point. At one point while investigating this
problem, xfree86 regularly hung with XFree86.0.log messages of the form
"R128(0) ... engine idle timeout ... resetting". This specific form of
a hang went away when I overrode BIOS PCI interrupt settings to the two
PCI r128 cards, to give them distinct interrupt lines. This configuration
hange appeared to become necessary only with the XFree86 version provided
with RHL 8.0, not with 7.2.
Cc'ing alan/arjan in case they can offer any comments
The IRQ is only used for direct render and DRI - so it would be interesting to
know what is happening there. Otherwise I don't see any obvious reasons for
problems beyond X server or hw bugs (pci deadlocks, incorrect resource handling
in X etc)
I have been having a very similar problem on my system with RedHat 8.0.
Here is my card:
Bus 0, device 9, function 0:
VGA compatible controller: ATI Technologies Inc Rage 128 PP/PRO TMDS
Master Capable. Latency=32. Min Gnt=8.
Prefetchable 32 bit memory at 0xd4000000 [0xd7ffffff].
I/O at 0xdc00 [0xdcff].
Non-prefetchable 32 bit memory at 0xd9000000 [0xd9003fff].
If I use the default configuration, from the 8.0 installer, the X server
starts looping if I do something which involves a lot of bitblts, such
an opaque window move or resize, or popping up various emacs menus (which
fall outside the main emacs window). Sometimes the X server loops,
but I can access the machine over the network. Sometimes the X server
hangs the machine completely, and turns off video refresh, so the monitor
goes to power saving mode. If I can access the machine, I can kill the
X server, but then the restarted X server just hangs again. I will attach
the X server configuration. Note that I can completely avoid the problem
by using the "VESA generic" (essentially "SVGA") driver, at some cost in
performance and visual clarity.
Created attachment 88145 [details]
Log of XFree86 startup with r128 driver
fche) With the official binaries (not your edited version), does disabling
DRI in the config file make the problem go away? Just comment out
the Load "dri" line and restart.
Does that work?
Nope, DRI does not appear related. The server used to hang the same way
with or without DRI loaded.
The newest XFree86-4.2.1-20 rpm still has this problem.
The same trick (hex-editing /usr/X11R6/bin/XFree86 s/RENDER/RENDAR/)
Likewise for XFree86-4.2.1-21. Given that fixing the real
bug is likely too hard, can you at least arrange to add a
"-norender" flag or somesuch to XFree86, so I don't have to
hand-edit the server binary every time an up2date goes a
little too far?
An additional data point. Similar flavoured hangs occur on a
different machine (using 3 Matrox Millennium II cards) running Fedora
Core 1. After binary-editing the XFree86 binary in the exact same
way, the server is stable. It could be a coincidence, or it could be
a sign that multiheaded machines don't play well with RENDER.
This annoying bug is still present in Fedora Core 2, with
yet another different hardware configuration.
Please provide a supported method to turn off RENDER until
the underlying bug is fixed.
Turning off Render would make a nasty mess of several thigns we ship.
A flag to turn off Render *ACCELERATION* for the card would make
sense, although it probably belongs upstream now we have X.org and a
sane contributor process
I was only ever talking about render acceleration (the RENDER X11
The RENDER extension, and "RENDER acceleration" are two completely
different things. The RENDER extension provides extended
functionality over core X11 protocol. "RENDER acceleration" is a
feature (or lack thereof) in a given driver for accelerating the
RENDER operations. The ATI Rage 128 (r128) driver does not
have any RENDER acceleration functions.
I agree with Alan above, about the configuration option request,
which should be an upstream request. Feel free to file a bug report
upstream at http://bugs.freedesktop.org if you wish, requesting
a new commandline option that disables the RENDER extension.
I agree with Alan again though, that it would make our desktop a
I've attempted to reproduce the problem described here in the past
unsuccessfully, so it's probably a good idea to also file this bug
upstream as well, as there don't seem to be many people who
experience this problem recorded in bugzilla. If it's upstream,
there's a higher chance someone might be able to reproduce it and
investigate the issue.
If you paste the upstream bug report URLs here, I'll also track
the issue upstream.
Kevin Martin implemented a new config file option set for disabling
extensions. Currently, it supports ability to disable the COMPOSITE,
and RENDER extensions, and possibly others as well. The details of
which can be found in X.Org documentation, or in the source code,
google, mailing lists, etc....
Closing as "RAWHIDE".