[Intel-gfx] glx application stall

[Martijn Wijns]

Hi,

We found the culprit: the DirectFB X11 input event thread caused a race 
condition with xcb_conn_wait. Just before xcb_conn_wait would do a poll 
it read out the socket causing the poll to block until new input 
arrives. We added spinlock to prevent this race condition until xcb gets 
fixed.

Best regards,
Martijn Wijns

On 11/26/2010 11:19 AM, Martijn Wijns wrote:
> 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
>
>
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>