On Tue, Nov 30, 2010 at 6:22 PM, Joris Dobbelsteen <[email protected]> wrote: > Hi all, > > I'm looking for some expert opinion to verify a possible cause of our > problems. > > After further investigation of the issue the following is found: > We do all our X drawing on a single thread. > However, DirectFB (used due to legacy reasons) creates a second thread > for reading inputs (events). > > Could this multi-threaded usage of libX11 cause it to hang? > > What we see is that our drawing thread gets stuck in a poll on the > socket while calling _XReply (after _XReply has called _XSend). However, > a second thread is seen reading from a socket for inputs. >
Does someone set the connection to thread safe mode? If yes then xcb might be causing the problem. > Thanks, > > - Joris Dobbelsteen > > On Fri, 2010-11-26 at 18:14 +0100, Joris Dobbelsteen wrote: >> Hi all, >> >> I'm having an application which is hanging after a call to >> DRI2GetBuffersWithFormat in mesa. >> >> I am looking for support with the issue and how to diagnose it. >> >> The issue is that our application is hanging at some point waiting for >> the X server to respond. >> One workaround is to move the mouse, which seems to generate events and >> that makes the communication get back on track. >> >> The issue has been very consistent, occurring at most 5 minutes after >> the x server is started and usually sooner. The issue does not occur in >> Ubuntu 10.10, which means there is a difference somewhere. >> >> The stack trace for the X client we are consistently getting is: >> #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 >> >> I see the X server getting a request and sending a reply. After this >> it's back in the waiting for command state: >> >> #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 ?? () >> >> With DEBUG_COMMUNICATION in os/io.c defined, I see the following output: >> [snip] >> REPLY: ClientIDX: 6 XEvent: type: 0xe detail: 0x0 seq#: 0x161b >> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5 >> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0xe1 len: 5 seq#: 0x161c >> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5 >> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0x63 len: 5 seq#: 0x161d >> REQUEST: ClientIDX: 6, type: 0x3e data: 0x7 len: 7 >> REPLY: ClientIDX: 6 XEvent: type: 0xe detail: 0x0 seq#: 0x161e >> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5 >> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0xe1 len: 5 seq#: 0x161f >> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5 >> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0x63 len: 5 seq#: 0x1620 >> REQUEST: ClientIDX: 6, type: 0x3e data: 0x7 len: 7 >> REPLY: ClientIDX: 6 XEvent: type: 0xe detail: 0x0 seq#: 0x1621 >> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5 >> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0xe1 len: 5 seq#: 0x1622 >> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5 >> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0x63 len: 5 seq#: 0x1623 >> REQUEST: ClientIDX: 6, type: 0x3e data: 0x7 len: 7 >> REPLY: ClientIDX: 6 XEvent: type: 0xe detail: 0x0 seq#: 0x1624 >> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5 >> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0xe1 len: 5 seq#: 0x1625 >> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5 >> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0x63 len: 5 seq#: 0x1626 >> REQUEST: ClientIDX: 6, type: 0x3e data: 0x7 len: 7 >> REPLY: ClientIDX: 6 XEvent: type: 0xe detail: 0x0 seq#: 0x1627 >> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5 >> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0xe1 len: 5 seq#: 0x1628 >> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5 >> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0x63 len: 5 seq#: 0x1629 >> REQUEST: ClientIDX: 6, type: 0x3e data: 0x7 len: 7 >> REPLY: ClientIDX: 6 XEvent: type: 0xe detail: 0x0 seq#: 0x162a >> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5 >> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0xe1 len: 5 seq#: 0x162b >> REQUEST: ClientIDX: 6, type: 0x86 data: 0x7 len: 5 >> REPLY: ClientIDX: 6 Xreply: type: 0x1 data: 0x63 len: 5 seq#: 0x162c >> >> It keeps waiting there till I move the mouse and see more REPLY >> responses in a line. >> >> There is the faint impression that the xserver does something wrong with >> buffering the message, and not flushing it. What is the right approach >> to see when the message is actually written to the socket? >> There seems to be quite a lot of cleverness around writing to the >> socket, probably for performance reasons. >> >> >> Note: this is the same issue as: >> <http://lists.freedesktop.org/archives/intel-gfx/2010-November/008850.html> >> >> Used software (somewhat updated in the meanwhile): >> * Linux 2.6.37-rc3, but same issue with 2.6.36 (and I think with 2.5.35 >> as well, but I'm not completely sure). >> * mesa 7.9. >> * xf86-video-intel 2.12.0, 2.13.0, 2.13.901. >> * libdrm 2.4.22 (and today's trunk, as it had a lot of intel patches). >> >> The issue looks very much the same as: >> <http://www.pubbs.net/201003/xorg/2227-problem-using-an-mesa-based-app-with-recent-xorgmesaxf86-video-intelloop.html> >> >> Thanks in advance, >> >> - Joris >> >> _______________________________________________ >> [email protected]: X.Org development >> Archives: http://lists.x.org/archives/xorg-devel >> Info: http://lists.x.org/mailman/listinfo/xorg-devel >> > > > _______________________________________________ > [email protected]: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel > _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
