Bug 78916

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".