Hi Jesse, Am 07.03.2010 00:11, schrieb Jesse Barnes: > It would help to know what the server is doing at this point with the > client. It may be that it put the client to sleep and hasn't woken it > up yet, or there could be something wrong with our getbuffers code in > the new scheme. > > dont know if this help:
strace output from Xorg (1.1MB): http://sources.openelec.tv/tmp/logfile/xbmc/Xorg.strace strace output from my Application (1.4MB): http://sources.openelec.tv/tmp/logfile/xbmc/xbmc.strace i have only strace and gdb installed for debugging, let me know if i need other programs for debugging. Stephan > Jesse > > On Sat, 06 Mar 2010 18:02:51 +0100 > Stephan Raue<mailingli...@openelec.tv> wrote: > > >> looks this like my problems that i have reported some days ago with >> Subject "Problem using an Mesa based App with recent >> xorg/mesa/xf86-video-intel (loop?)" to Mesa-dev, xorg and intel-gfx list? >> >> i have still this issue, but i dont know what you need for informations >> to fix the issues? >> >> with ati driver i dont have problems, only here with intel driver on my >> Thinkpad X200t with intel HDA Graphics card >> >> Stephan >> >> Am 06.03.2010 17:46, schrieb Maxim Levitsky: >> >>> On Sat, 2010-03-06 at 08:02 -0800, Jesse Barnes wrote: >>> >>> >>>> On Sat, 06 Mar 2010 16:40:27 +0200 >>>> Maxim Levitsky<maximlevit...@gmail.com> wrote: >>>> >>>> >>>> >>>>> On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote: >>>>> >>>>> >>>>>> On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote: >>>>>> >>>>>> >>>>>>> On Fri, 05 Mar 2010 23:48:48 +0200 >>>>>>> Maxim Levitsky<maximlevit...@gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On Fri, 05 Mar 2010 23:18:07 +0200 >>>>>>>>> Maxim Levitsky<maximlevit...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Fri, 05 Mar 2010 22:42:21 +0200 >>>>>>>>>>> Maxim Levitsky<maximlevit...@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> After quite long period of inactivity, I updated graphical stack >>>>>>>>>>>> on my >>>>>>>>>>>> desktop/server. >>>>>>>>>>>> >>>>>>>>>>>> To say the truth, I did such update about month ago, but found out >>>>>>>>>>>> that >>>>>>>>>>>> X refuses flatly to use DRI modules. I assumed that it was my >>>>>>>>>>>> mistake in >>>>>>>>>>>> compilation process (although it is automated). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> That generally indicates a build or config problem of some kind. >>>>>>>>>>> Did >>>>>>>>>>> you ever narrow it down? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Because the same compile process works now, I suspect that wasn't >>>>>>>>>> build >>>>>>>>>> failure. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Well something weird is going on; maybe you didn't build X after Mesa >>>>>>>>> or with the right Mesa includes? >>>>>>>>> >>>>>>>>> >>>>>>>> I am very sure that this issue isn't relevant now. >>>>>>>> >>>>>>>> I do compile (libdrm, mesa, xserver, xf86-intel, and evdev driver in >>>>>>>> that order, compiling everything from scratch (doing git clean -dfx in >>>>>>>> all directories) >>>>>>>> >>>>>>>> >>>>>>> if you just want a working setup, perhaps you should try using >>>>>>> something that got (probably) tested by at least some people: >>>>>>> http://intellinuxgraphics.org/2009Q4.html >>>>>>> cheers, >>>>>>> Flo >>>>>>> >>>>>>> >>>>>> Well, I now have a working setup with mesa >>>>>> ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5 >>>>>> >>>>>> The problem is that I hoped that once all heavy work in regard to KMS >>>>>> was done, there will be no serious regressions in 3D stack, but only bug >>>>>> fixes, because it is very hard to track and fix bugs there. >>>>>> >>>>>> However, once again 3D stack is in bad shape, and this is not good. >>>>>> >>>>>> >>>>> More testing shows the following behaviour: >>>>> >>>>> >>>>> >>>>> Full screen mode is completely busted. As soon as any 3D application >>>>> switches to full screen mode, even without changing the resolution, it >>>>> hangs (note that I didn't see GPU hangs due to that) >>>>> >>>>> Compiz is broken (its also a full screen app...). As soon as it starts, >>>>> it draws few windows, and then stalls. >>>>> >>>>> In window mode all applications do work. >>>>> >>>>> >>>>> Now I guess this is worth a bugzilla entry. >>>>> (If this isn't there yet...) >>>>> >>>>> >>>> I'm not seeing this on GM45. I just installed a totally fresh stack on >>>> a new F12 installation and compiz and games work well. But please file >>>> a bug and include everything needed (see intellinuxgraphics.org for the >>>> list); hope we can find the issue. >>>> >>>> >>> Here, gdb backtrace while running sauerbraten full screen: >>> >>> >>> #2 0xb6e93d80 in ?? () from /usr/lib/libxcb.so.1 >>> #3 0xb6e959d2 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1 >>> #4 0xb7387e7e in _XReply (dpy=0x9023938, rep=0xbfc6a4dc, extra=0, >>> discard=0) at xcb_io.c:454 >>> #5 0xb772ba30 in DRI2GetBuffersWithFormat (dpy=0x9023938, >>> drawable=62914575, width=0x93eed74, height=0x93eed78, >>> attachments=0xbfc6a5dc, count=2, >>> outCount=0xbfc6a608) at dri2.c:428 >>> #6 0xb7729f62 in dri2GetBuffersWithFormat (driDrawable=0x93eed50, >>> width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2, >>> out_count=0xbfc6a608, >>> loaderPrivate=0x93eecb0) at dri2_glx.c:435 >>> #7 0xb6557bf3 in intel_update_renderbuffers (context=0x905c678, >>> drawable=0x93eed50) at intel_context.c:253 >>> #8 0xb65581d5 in intel_prepare_render (intel=0x90c6c50) at >>> intel_context.c:395 >>> #9 0xb657a423 in brw_try_draw_prims (ctx=<value optimized out>, >>> arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 >>> '\001', >>> min_index=0, max_index=3) at brw_draw.c:340 >>> #10 brw_draw_prims (ctx=<value optimized out>, arrays=0x910418c, >>> prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', >>> min_index=0, max_index=3) >>> at brw_draw.c:441 >>> #11 0xb663ea64 in vbo_exec_vtx_flush (exec=0x9102b30, unmap=1 '\001') at >>> vbo/vbo_exec_draw.c:384 >>> #12 0xb663a42a in vbo_exec_FlushVertices_internal (ctx=0xfffffdfc, >>> unmap=255 '\377') at vbo/vbo_exec_api.c:872 >>> #13 0xb663c230 in vbo_exec_FlushVertices (ctx=0x90c6c50, flags=1) at >>> vbo/vbo_exec_api.c:906 >>> #14 0xb65daea5 in _mesa_set_enable (ctx=0x90c6c50, cap=3042, state=1 >>> '\001') at main/enable.c:283 >>> #15 0xb65db1bf in _mesa_Enable (cap=3042) at main/enable.c:1007 >>> #16 0x080abf08 in ?? () >>> #17 0x080ad3fc in ?? () >>> #18 0xb7479b56 in __libc_start_main (main=0x80ad0a0, argc=3, >>> ubp_av=0xbfc6abb4, init=0x824a9f0, fini=0x824a9e0, >>> rtld_fini=0xb789cd20<_dl_fini>, >>> >>> >>> Best regards, >>> Maxim Levitsky >>> >>> _______________________________________________ >>> Intel-gfx mailing list >>> intel-...@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx >>> >>> >>> >> >> > > -- ### OpenELEC.tv ### The free and open Mediacenter Distribution 4 you http://www.openelec.tv ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
