Bug 73479

is this an smp machine?
also does "dmesg" show anything weird (like an oops) at the end ?

My box is a P4 UP i850 running kernel-2.4.18-14.i686.rpm. dmesg does not show
anything bad after startup,

agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 203M
agpgart: Detected Intel i850 chipset
agpgart: AGP aperture is 128M @ 0xe8000000
[drm] AGP 0.99 on Intel i850 @ 0xe8000000 128MB
[drm] Initialized radeon 1.1.1 20010405 on minor 0

This might be a XFree86 bug, I can't tell.

It is definitely a bug with either XFree86 or DRM.  If the machine locks
hard, then it almost certainly has to be a DRM bug.  I have reproduced
this before on a Serverworks chipset (OSB4) with Radeon 64 DDR.

I do not think it is hardware related.  Also, it is aparently fixed in
DRI-CVS, but last I recall hearing, it just got fixed along the road,
and nobody knows exactly what the problem was or when it got fixed.
It is possible the bug exists in DRM still, and X just no longer
triggers it too.

I will chat with Kevin Martin about this and see if we can perhaps
figure it out.  I can't run Wolf3D on Radeon either anymore.  ;o)

The Wolf3D demo works fine though.

Tim Smith might be interested in peeking at this one too..  He seems
very good at debugging nasty X problems with DRI.  ;o)

Where else in the world can one get a job where one is payed to
play cutting edge 3D video games to solve customer problems?

I love my job.

Adding Kevin to CC...

Tim Smith wrote a patch to test for this...  Will test soon.

Would wolf3D run with 3d disabled? It will be a dog but if theirs no lockups
then we know it's a DRM issue.

I ran across this patch as dri.sourceforge.net and thought it might
be useful here.

Summary: Radeon lockups with to many cliprects. This patch fixes bug
'[565927] ATI Radeon freezes system'.

In function radeonClear when number of clipping rectandles exceeds
RANEON_NR_SAREA_CLIPRECTS the driver enteres infininite loop having
hardware lock and hangs XServer which waits for this lock (I think
so ;-)).

File to be patched
'xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c'.

(this is not in unified diff form)

791d790
<          nr = rmesa->sarea->nbox;
793,798c792,797
<          for ( i = 0 ; i < nr ; i++ ) {
<            depth_boxes[i].f[RADEON_CLEAR_X1] = (float)b[i].x1;
<            depth_boxes[i].f[RADEON_CLEAR_Y1] = (float)b[i].y1;
<            depth_boxes[i].f[RADEON_CLEAR_X2] = (float)b[i].x2;
<            depth_boxes[i].f[RADEON_CLEAR_Y2] = (float)b[i].y2;
<            depth_boxes[i].f[RADEON_CLEAR_DEPTH] = 
---
>          for ( --n; n >= 0; n-- ) {
>            depth_boxes[n].f[RADEON_CLEAR_X1] = (float)b[n].x1;
>            depth_boxes[n].f[RADEON_CLEAR_Y1] = (float)b[n].y1;
>            depth_boxes[n].f[RADEON_CLEAR_X2] = (float)b[n].x2;
>            depth_boxes[n].f[RADEON_CLEAR_Y2] = (float)b[n].y2;
>            depth_boxes[n].f[RADEON_CLEAR_DEPTH] = 

Please attach a unified diff as a bugzilla file attachment and I'll
have a look.

Fedora Core 2, wolf seems to work on Radeon hardware ok without any
lockups, so I'm assuming this problem was fixed in CVS and made it
into newer X releases.

If you do encounter the problem again however, please file a bug
report in X.Org bugzilla at http://bugs.freedesktop.org in the
"xorg" component.  Make sure when attaching patches to bugzilla
reports in freedesktop.org or Red hat bugzilla to always generate
unified diffs, and to attach them using bugzilla file attach
feature in order for the patches to be reviewed by an engineer.

Thanks.

Setting status to "CURRENTRELEASE"