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 card - 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. How reproducible: Sometimes 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. Additional info: I will attach my current xf86 config and log files, and lspci.
Created attachment 87227 [details] XF86Config
Created attachment 87228 [details] XFree86.0.log
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 (rev 0). IRQ 11. 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/) still works.
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 extension).
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 mess however. 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.
http://freedesktop.org/bugzilla/show_bug.cgi?id=831
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".