[Intel-gfx] glx application stall

[Martijn Wijns]

Hi,

When running our DirectFB/X11/glx application it stalls after a few 
seconds of not using the mouse. This is the stacktrace from the 
application point of view:

#0  0xb7741424 in __kernel_vsyscall ()
#1  0xb6d269b4 in pthread_cond_wait () from /lib/libpthread.so.0
#2  0xb6a03344 in ?? () from /usr/lib/libX11.so.6
#3  0xb6a02d2f in ?? () from /usr/lib/libX11.so.6
#4  0xb6a1e0d3 in _XReply () from /usr/lib/libX11.so.6
#5  0xb5de69a3 in DRI2GetBuffersWithFormat (dpy=0x8397fa0, 
drawable=10485772, width=0x88dd5a4, height=0x88dd5a8, 
attachments=0xbfaf0098, count=1,
     outCount=0xbfaf00c4) at dri2.c:454
#6  0xb5de478f in dri2GetBuffersWithFormat (driDrawable=0x88dd580, 
width=0x88dd5a4, height=0x88dd5a8, attachments=0xbfaf0098, count=1, 
out_count=0xbfaf00c4,
     loaderPrivate=0x88dd4e0) at dri2_glx.c:582
#7  0xb5a7d3df in intel_update_renderbuffers (context=0x835f260, 
drawable=0x88dd580) at intel_context.c:290
#8  0xb5a7d8cc in intel_prepare_render (intel=0x83997c0) at 
intel_context.c:438
#9  0xb5a7a99d in i915_render_start (intel=0x83997c0) at i915_vtbl.c:58
#10 0xb5a8ed9b in intelRenderStart (ctx=0x83997c0) at intel_tris.c:1087
#11 0xb5b888b3 in run_render (ctx=0x83997c0, stage=0x8607d88) at 
tnl/t_vb_render.c:276
#12 0xb5b7cb84 in _tnl_run_pipeline (ctx=0x83997c0) at tnl/t_pipeline.c:153
#13 0xb5a8f07d in intelRunPipeline (ctx=0x83997c0) at intel_tris.c:1075
#14 0xb5b7d284 in _tnl_draw_prims (ctx=0x83997c0, arrays=0x85f5e1c, 
prim=0x85f47f0, nr_prims=1, ib=0x0, min_index=0, max_index=3) at 
tnl/t_draw.c:478
#15 0xb5b7dd86 in _tnl_vbo_draw_prims (ctx=0x83997c0, arrays=0x85f5e1c, 
prim=0x85f47f0, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', 
min_index=0,
     max_index=3) at tnl/t_draw.c:384
#16 0xb5b75667 in vbo_exec_vtx_flush (exec=0x85f46b8, unmap=1 '\001') at 
vbo/vbo_exec_draw.c:384
#17 0xb5b72560 in vbo_exec_FlushVertices_internal (ctx=0x83997c0, 
unmap=0 '\0') at vbo/vbo_exec_api.c:876
#18 0xb5b72638 in vbo_exec_FlushVertices (ctx=0x83997c0, flags=1) at 
vbo/vbo_exec_api.c:910
#19 0xb5b4bb79 in _mesa_BindTexture (target=34037, texName=19) at 
main/texobj.c:1058
#20 0xb5df80b1 in glBindTexture (target=34037, texture=19) at 
../../../src/mapi/glapi/glapitemp.h:1627
#21 0xb4a10e44 in glSetState () from 
/usr/lib/directfb-1.4-5-pure/gfxdrivers/libdirectfb_gl.so
#22 0xb6dc3ee1 in ?? () from /usr/lib/libdirectfb-1.4.so.5
#23 0xb6dc698c in dfb_gfxcard_blit () from /usr/lib/libdirectfb-1.4.so.5
#24 0xb6d78679 in ?? () from /usr/lib/libdirectfb-1.4.so.5
#25 0xb6e01825 in IDirectFBSurface::Blit () from /usr/lib/lib++dfb-1.0.so.0

The X server appears to be doing a select syscall:

#0  0xb76fb424 in __kernel_vsyscall ()
#1  0xb73c07cd in select () from /lib/libc.so.6
#2  0x0809bb28 in WaitForSomething ()
#3  0x0806e0ae in ?? ()
#4  0x092b0da8 in ?? ()
#5  0x00000002 in ?? ()
#6  0x00000000 in ?? ()

The i915 driver reports:

[drm] i915_gem_retire_request: retire 507 moves to inactive list e7702960
[drm] i915_gem_retire_request: retire 507 moves to inactive list e03d2e10
[drm] i915_gem_retire_request: retire 507 moves to inactive list e7702d20

but /sys/kernel/debug/dri/0 shows:

Flushing:
     e7702960: p  8388608 00000002 00000002 0 dirty (name: 1) (fence: 0) 
(gtt_offset: 01000000)

/sys/kernel/debug/dri/0/i915_error_state shows:
no error state collected

/sys/kernel/debug/dri/0/i915_wedged:
wedged :  0

When I move the mouse, everything works again for a few seconds.

I tested it with glxgears and glxgears keeps running. Also when glxgears 
is started when our own application is waiting on the 
DRI2GetBuffersWithFormat glxgears runs and updates properly. Our 
application keeps waiting until glxgears is closed, then it updates for 
a while and stops again. While glxgears is running the object that was 
in de flushing queue remains in the flushing queue.

We're running:
Linux 2.6.36
Xorg 1.9.2
Mesa 7.9
libdrm 2.4.22
xorg-driver-video-intel 2.13.0

When running our application on freshly installed ubuntu maverick on the 
same board it keeps running without stalling. Right now we're trying to 
find the differences between the two situations that explain the problem 
and trying to gather perf tracing of the problem. Any ideas about what 
it could be or how to properly debug this would be greatly appreciated.

Best regards,
Martijn Wijns