Bug 715

OVERVIEW:
In heavy activity involving texturing, after a certain time, the
system locks hard.  The mouse cursor moves with the mouse; but
no other input of any sort has any effect (including attempts
to change virtual terminal).  A full system reset is necessary.


REPRODUCING THIS BUG:
Unfortunately, this bug is hard to reproduce in a systematic fashion.
I can guarantee that if, for example,  you spend enough time flying
around close to the ground in FlightGear, the machine will lock up
in this fashion.  But I can't guarantee that "if you do X, Y, and Z
in sequence, it'll lock up."  But while it's not easily reproduced in
a systematic fashion, it is easily reproduced in that it comes up for
me quite frequently (I'm currently running into this several times a
week, and sometimes multiple times a night).

If there are things someone would want me to do to collect more info
in order to run the problem down (e.g. apply a patch to write a bunch
of info to the XF86 log when the idle timeout message below occurs),
I'm happy to do that.


WHAT HAPPENS:
As noted, the system locks hard.  Mouse movement moves the mouse
cursor around; but no other input has any effect, and all screen
updates (other than the mouse cursor) cease.

I've experienced this bug since XF86 4.0; it may have been present in
earlier versions, but I didn't have the G550 before I started using that
version of XFree86.  I hadn't reported it until recently because I was
getting no useful information about the crash; I didn't know whether it
was a problem with applications, the X server, user (X server) modules,
kernel modules, or the app itself.  But with XF86 4.3, when the lockup
occurs, I'm now getting an endless (well, thousands of instances) write
of:

(EE) MGA(0): [dri] Idle timed out, resetting engine...
(EE) MGA(0): [dri] Idle timed out, resetting engine...
(EE) MGA(0): [dri] Idle timed out, resetting engine...
(EE) MGA(0): [dri] Idle timed out, resetting engine...
....

into XFree86.0.log, until the machine is reset.


BUG IS PRESENT IN:
DRI CVS Snapshot 20040527 as well as XFree86 4.x.

PLATFORM:
I have a Matrox G550 on a Via KT333-based board (Asus A7V333).
I run Linux kernel 2.4.23.  I do not use the proprietary/optional
mga_hal driver from Matrox.

ADDITIONAL NOTES:
- For 2D use, everything's fine.  For simple 3D use (e.g. glxgears,
rendering within blender, or the typical OpenGL-based screensaver),
it's fine.  This problem only occurs with intensive 3D use that
involves a lot of texture writing/mapping/shading/etc.

- This bug was previously reported on the DRI bugtracker at
Sourceforge.  However, Ian Romanick informed me that the BTS
there is deprecated, and that this was the one to use as soon as
it was up.

- This bug may be the same as

http://freedesktop.org/bugzilla/show_bug.cgi?id=473

except I don't get it immediately upon starting up an app,
and I don't get it with simple OpenGL apps like glxgears.

- This bug may also be related to this bug reported by
Ian Romanick:

http://sourceforge.net/tracker/index.php?func=detail&aid=546281&group_id=387&atid=100387

I simly don't know enough to say.

Please let me know if there's anything I can do to provide
more information or test anything.