On Fri, 2003-11-28 at 13:00, Andreas Stenglein wrote:
>
> I found another program using scissors that triggers
> (maybe) the same bug: lesson24 from nehe.gamedev.net
> http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=24
> (glut and sdl source)
> The difference is: when triggering the bug with q3a
> both gl-apps exit() with r200WaitIrq: drmRadeonIrqWait: -16
> and the Xserver loops, no cursor-movement...
> when triggering the bug with lesson24, one program loops
> and gets #1 in top (99,x% CPU), and you have at least
> a moving cursor. After killing -KILL the programs, the Xserver
> becomes #1 -> now you have the same result you get with quake3.
Sounds like different symptoms of a chip lockup.
This patch doesn't happen to make a difference, does it?
> > > What needs to be defined in host.def to get better debug-info in the
> > > static build? (XFree86 CVS HEAD)
> >
> > What kind of information are you thinking of?
>
> I thought of linenumbers and variable names.
> Both are there when building from DRI CVS, but none of them
> is there when building XFREE86 CVS HEAD.
I guess XFree86 CVS doesn't build with -g by default. You can always
rebuild any parts you want debugging info for with makeg.
--
Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer
Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer
Index: programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeon_state.c
===================================================================
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeon_state.c,v
retrieving revision 1.8
diff -p -u -r1.8 radeon_state.c
--- programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeon_state.c 28 Sep 2003 20:16:09 -0000 1.8
+++ programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeon_state.c 28 Nov 2003 15:11:17 -0000
@@ -47,7 +47,11 @@ static __inline__ void radeon_emit_clip_
DRM_DEBUG( " box: x1=%d y1=%d x2=%d y2=%d\n",
box->x1, box->y1, box->x2, box->y2 );
- BEGIN_RING( 4 );
+ /* FIXME send a WAIT_UNTIL_3D_IDLE before writing to the scissor
+ * registers to avoid lockups
+ */
+ BEGIN_RING( 6 );
+ RADEON_WAIT_UNTIL_3D_IDLE();
OUT_RING( CP_PACKET0( RADEON_RE_TOP_LEFT, 0 ) );
OUT_RING( (box->y1 << 16) | box->x1 );
OUT_RING( CP_PACKET0( RADEON_RE_WIDTH_HEIGHT, 0 ) );
@@ -1941,23 +1945,6 @@ static int radeon_emit_packet3_cliprect(
if ( i < cmdbuf->nbox ) {
if (DRM_COPY_FROM_USER_UNCHECKED( &box, &boxes[i], sizeof(box) ))
return DRM_ERR(EFAULT);
- /* FIXME The second and subsequent times round
- * this loop, send a WAIT_UNTIL_3D_IDLE before
- * calling emit_clip_rect(). This fixes a
- * lockup on fast machines when sending
- * several cliprects with a cmdbuf, as when
- * waving a 2D window over a 3D
- * window. Something in the commands from user
- * space seems to hang the card when they're
- * sent several times in a row. That would be
- * the correct place to fix it but this works
- * around it until I can figure that out - Tim
- * Smith */
- if ( i ) {
- BEGIN_RING( 2 );
- RADEON_WAIT_UNTIL_3D_IDLE();
- ADVANCE_RING();
- }
radeon_emit_clip_rect( dev_priv, &box );
}
