Using the development version of Fedora 21, I can see Epiphany (GNOME's WebKitGTK based browser) hang whenever a video is supposed to be presented on-screen. Running: LIBGL_DRI3_DISABLE=1 epiphany works around the problem. mesa-dri-drivers-10.2.3-1.20140711.fc21.x86_64 kernel-3.16.0-0.rc5.git1.2.fc22.x86_64 Backtrace of the hang: #0 0x00007f6143b23a1d in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f613bbd7142 in _xcb_conn_wait () at /lib64/libxcb.so.1 #2 0x00007f613bbd8609 in xcb_wait_for_special_event () at /lib64/libxcb.so.1 #3 0x00007f613f9582a4 in dri3_find_back () at /lib64/libGL.so.1 #4 0x00007f613f9588a5 in dri3_get_buffer.isra () at /lib64/libGL.so.1 #5 0x00007f613f959295 in dri3_get_buffers () at /lib64/libGL.so.1 #6 0x00007f608262daf7 in intel_update_renderbuffers () at /usr/lib64/dri/i965_dri.so #7 0x00007f608262de25 in intel_prepare_render () at /usr/lib64/dri/i965_dri.so #8 0x00007f6082632000 in brw_draw_prims () at /usr/lib64/dri/i965_dri.so #9 0x00007f608248c59e in vbo_draw_arrays () at /usr/lib64/dri/i965_dri.so #10 0x00007f6148c23cda in WebCore::TextureMapperGL::drawUnitRect(WebCore::TextureMapperShaderProgram*, unsigned int) (this=this@entry=0x7f60a0e41240, program=program@entry= 0x7f6082b45b00, drawingMode=drawingMode@entry=6) at Source/WebCore/platform/graphics/texmap/TextureMapperGL.cpp:634 #11 0x00007f6148c240a2 in WebCore::TextureMapperGL::draw(WebCore::FloatRect const&, WebCore::TransformationMatrix const&, WebCore::TextureMapperShaderProgram*, unsigned int, int) (this=this@entry=0x7f60a0e41240, rect=..., modelViewMatrix=..., shaderProgram=shaderProgram@entry=0x7f6082b45b00, drawingMode=drawingMode@entry=6, flags=1) at Source/WebCore/platform/graphics/texmap/TextureMapperGL.cpp:661 #12 0x00007f6148c24fb8 in WebCore::TextureMapperGL::drawTexturedQuadWithProgram(WebCore::TextureMapperShaderProgram*, unsigned int, int, WebCore::IntSize const&, WebCore::FloatRect const&, WebCore::TransformationMatrix const&, float) (this=this@entry=0x7f60a0e41240, program=program@entry=0x7f6082b45b00, texture=texture@entry=1, flags=<optimized out>, flags@entry=1, size=..., rect=..., modelViewMatrix=..., opacity=opacity@entry=1) at Source/WebCore/platform/graphics/texmap/TextureMapperGL.cpp:694 #13 0x00007f6148c255d3 in WebCore::TextureMapperGL::drawTexture(unsigned int, int, WebCore::IntSize const&, WebCore::FloatRect const&, WebCore::TransformationMatrix const&, float, unsigned int) (this=this@entry=0x7f60a0e41240, texture=<optimized out>, flags=<optimized out>, flags@entry=1, textureSize=..., targetRect=..., modelViewMatrix=..., opacity=opacity@entry=1, exposedEdges=15) at Source/WebCore/platform/graphics/texmap/TextureMapperGL.cpp:574 #14 0x00007f6148c1ff36 in WebCore::TextureMapperGL::drawTexture(WebCore::BitmapTexture const&, WebCore::FloatRect const&, WebCore::TransformationMatrix const&, float, unsigned int) (this=0x7f60a0e41240, texture=..., targetRect=..., matrix=..., opacity=1, exposedEdges=15) at Source/WebCore/platform/graphics/texmap/TextureMapperGL.cpp:530 #15 0x00007f6148c37e84 in WebCore::TextureMapperTile::paint(WebCore::TextureMapper*, WebCore::TransformationMatrix const&, float, unsigned int) (this=<optimized out>, textureMapper=0x7f60a0e41240, transform=..., opacity=<optimized out>, exposedEdges=15) at Source/WebCore/platform/graphics/texmap/TextureMapperTile.cpp:75 #16 0x00007f6148c395d9 in WebCore::TextureMapperTiledBackingStore::paintToTextureMapper(WebCore::TextureMapper*, WebCore::FloatRect const&, WebCore::TransformationMatrix const&, float) (this=0x7f6082bb96c8, textureMapper=0x7f60a0e41240, targetRect=..., transform=..., opacity=1) at Source/WebCore/platform/graphics/texmap/TextureMapperTiledBackingStore.cpp:55 #17 0x00007f6148c32ece in WebCore::TextureMapperLayer::paintSelf(WebCore::TextureMapperPaintOptions const&) (this=this@entry=0x7f6092e71a00, options=...) at Source/WebCore/platform/graphics/texmap/TextureMapperLayer.cpp:139 #18 0x00007f6148c36f92 in WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions const&) (this=0x7f6092e71a00, options=...) at Source/WebCore/platform/graphics/texmap/TextureMapperLayer.cpp:176 #19 0x00007f6148c3715c in WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions const&) (this=0x7f6092e71a00, options=...) at Source/WebCore/platform/graphics/texmap/TextureMapperLayer.cpp:231 #20 0x00007f6148c36bbd in WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions const&) (this=0x7f6092e71a00, options=...) at Source/WebCore/platform/graphics/texmap/TextureMapperLayer.cpp:455 #21 0x00007f6148c36f0d in WebCore::TextureMapperLayer::paintSelfAndChildren(WebCore::TextureMapperPaintOptions const&) (this=0x7f60c4d5c500, options=...) at Source/WebCore/platform/graphics/texmap/TextureMapperLayer.cpp:191 #22 0x00007f6148c3715c in WebCore::TextureMapperLayer::paintSelfAndChildrenWithReplica(WebCore::TextureMapperPaintOptions const&) (this=0x7f60c4d5c500, options=...) at Source/WebCore/platform/graphics/texmap/TextureMapperLayer.cpp:231 #23 0x00007f6148c36bbd in WebCore::TextureMapperLayer::paintRecursive(WebCore::TextureMapperPaintOptions const&) (this=this@entry=0x7f60c4d5c500, options=...) at Source/WebCore/platform/graphics/texmap/TextureMapperLayer.cpp:455 #24 0x00007f6148c36ce6 in WebCore::TextureMapperLayer::paint() (this=0x7f60c4d5c500) at Source/WebCore/platform/graphics/texmap/TextureMapperLayer.cpp:92 #25 0x00007f6148252f57 in WebKit::LayerTreeHostGtk::compositeLayersToContext(WebKit::LayerTreeHostGtk::CompositePurpose) (this=this@entry= 0x7f6092ed5528, purpose=purpose@entry=WebKit::LayerTreeHostGtk::NotForResize) at Source/WebKit2/WebProcess/WebPage/gtk/LayerTreeHostGtk.cpp:341 #26 0x00007f6148253451 in WebKit::LayerTreeHostGtk::flushAndRenderLayers() (this=0x7f6092ed5528) at Source/WebKit2/WebProcess/WebPage/gtk/LayerTreeHostGtk.cpp:366 #27 0x00007f6148253566 in WebKit::LayerTreeHostGtk::layerFlushTimerFired() (this=0x7f6092ed5528) at Source/WebKit2/WebProcess/WebPage/gtk/LayerTreeHostGtk.cpp:301
Just a wild guess. Could it be related to Bug 80963? That's caused by libxcb bug though, the place of hanging is the same.
(In reply to comment #1) > Just a wild guess. Could it be related to Bug 80963? That's caused by libxcb > bug though, the place of hanging is the same. libxcb in F21 ships with the patch for that bug already.
I can confirm that the libxcb patch fixes the problem with Epiphany for me.
Sorry, ignore that last one, DRI3 was accidentally disabled when testing. Nope, still there. :(
Yeah. Just tested with xorg-server 1.16.0. Problem is still there with the fixed libxcb.
So, the patched libxcb does this: leto:/usr/include/xcb > grep PACKED *.h present.h:} XCB_PACKED xcb_present_complete_notify_event_t; present.h:} XCB_PACKED xcb_present_redirect_notify_event_t; xcb.h:#define XCB_PACKED __attribute__((__packed__)) I rebuilt mesa, xorg-server and xf86-video-intel against that new header, I hope that was correct.
I'm seeing the same issue. Note that at least on my system it's not a hang, but the epiphany is showing about 1FPS.. Playing a bit with systemtap it seems that the dri3_find_back function takes almost a second before returning...
(In reply to Sjoerd Simons from comment #7) > I'm seeing the same issue. Note that at least on my system it's not a hang, > but the epiphany is showing about 1FPS.. Playing a bit with systemtap it > seems that the dri3_find_back function takes almost a second before > returning... Since the symptoms are different and this might well be a separate issue, I've filed bug #85064 for this.
i see similar problems in recent mesa releases (last month or 2). my bt is missing symbols but it's the same idea - mesa gets stuck in a "get something from x" and never gets the reply. until 10.3.2 i could vt switch to text console and back to unstick it. this now no longer works to unstick. my bt is: #6 0x00007f8d73c4a5bd in poll () from /usr/lib/libc.so.6 #7 0x00007f8d70c919f2 in ?? () from /usr/lib/libxcb.so.1 #8 0x00007f8d70c932ff in ?? () from /usr/lib/libxcb.so.1 #9 0x00007f8d70c93411 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1 #10 0x00007f8d77dfe7c7 in _XReply () from /usr/lib/libX11.so.6 #11 0x00007f8d6d91c7f3 in ?? () from /usr/lib/libGL.so.1 #12 0x00007f8d6d919ef9 in ?? () from /usr/lib/libGL.so.1 #13 0x00007f8d6b426289 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so #14 0x00007f8d6b4267a5 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so #15 0x00007f8d6b42b674 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so #16 0x00007f8d6b282dce in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so #17 0x00007f8d6be1ba2b in shader_array_flush (gc=0x1fac4e0) at modules/evas/engines/gl_common/evas_gl_context.c:3270 that's a glDrawArrays() fyi. there that is called. yes the #6 on the bt stack is due to me forcing a segv (killall -SEGV) to get a bt automatically out of my wm. #6 is where it is stuck until i segv it.
Carsten, does this happen also with UXA instead of SNA? If you search bugzilla for "DRI3" there are still lot of issues with it, especially in combination with SNA (which is now default and clearly faster at least with DRI2).
I can't seem to reproduce this (with radeonsi). Does it still happen with libxcb 1.11.1 or newer, and current versions of Mesa and xserver? If yes, can you provide a link reproducing the problem?
Looks like the problem still exists on Ubuntu 15.10 with FF and oibaf ppa: #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007f4a27f0ee29 in _xcb_conn_wait (c=c@entry=0x7f4a1ba1a000, cond=cond@entry=0x7f4a061e05a8, vector=vector@entry=0x0, count=count@entry=0x0) at ../../src/xcb_conn.c:427 #2 0x00007f4a27f10089 in xcb_wait_for_special_event (c=0x7f4a1ba1a000, se=0x7f4a061e0580) at ../../src/xcb_in.c:716 #3 0x00007f49fe2de9c7 in dri3_find_back (draw=0x7f49d6ac07b8) at ../../../../src/loader/loader_dri3_helper.c:380 #4 0x00007f49fe2df822 in loader_dri3_get_buffers (driDrawable=<optimized out>, format=4098, stamp=0x7f49e10cd9b0, loaderPrivate=0x7f49d6ac07b8, buffer_mask=<optimized out>, buffers=0x7f4a03dfe590) at ../../../../src/loader/loader_dri3_helper.c:1193 #5 0x00007f49fcb611d7 in intel_update_renderbuffers (context=<optimized out>, drawable=0x7f49e10cd980) at ../../../../../../../src/mesa/drivers/dri/i965/brw_context.c:1628 #6 0x00007f49fcb615ae in intel_prepare_render (brw=0x7f49e109a028) at ../../../../../../../src/mesa/drivers/dri/i965/brw_context.c:1365 #7 0x00007f49fcb52763 in brw_clear (ctx=0x7f49e109a028, mask=2) at ../../../../../../../src/mesa/drivers/dri/i965/brw_clear.c:232 #8 0x00007f4a20497d13 in mozilla::gl::GLContext::fClear (this=0x7f49e10ff000, mask=mask@entry=16640) at /build/firefox-trunk-fYuA0y/firefox-trunk-47.0~a1~hg20160125r281515/obj-x86_64-linux-gnu/dist/include/GLContext.h:970 #9 0x00007f4a204a6a75 in mozilla::layers::CompositorOGL::BeginFrame (this=0x7f49ed870800, aInvalidRegion=..., aClipRectIn=0x0, aRenderBounds=..., aClipRectOut=0x7f4a03dfe800, aRenderBoundsOut=<optimized out>) at /build/firefox-trunk-fYuA0y/firefox-trunk-47.0~a1~hg20160125r281515/gfx/layers/opengl/CompositorOGL.cpp:717 #10 0x00007f4a2047b54c in mozilla::layers::LayerManagerComposite::Render (this=this@entry=0x7f49d6a650c0, aInvalidRegion=...) at /build/firefox-trunk-fYuA0y/firefox-trunk-47.0~a1~hg20160125r281515/gfx/layers/composite/LayerManagerComposite.cpp:851 #11 0x00007f4a2047bbec in mozilla::layers::LayerManagerComposite::UpdateAndRender (this=this@entry=0x7f49d6a650c0) at /build/firefox-trunk-fYuA0y/firefox-trunk-47.0~a1~hg20160125r281515/gfx/layers/composite/LayerManagerComposite.cpp:445 #12 0x00007f4a2047bd2e in mozilla::layers::LayerManagerComposite::EndTransaction (this=0x7f49d6a650c0, aTimeStamp=..., aFlags=aFlags@entry=mozilla::layers::LayerManager::END_DEFAULT) at /build/firefox-trunk-fYuA0y/firefox-trunk-47.0~a1~hg20160125r281515/gfx/layers/composite/LayerManagerComposite.cpp:367 #13 0x00007f4a20493093 in mozilla::layers::CompositorParent::CompositeToTarget (this=0x7f49e105ac00, aTarget=aTarget@entry=0x0, aRect=aRect@entry=0x0) at /build/firefox-trunk-fYuA0y/firefox-trunk-47.0~a1~hg20160125r281515/gfx/layers/ipc/CompositorParent.cpp:1251 #14 0x00007f4a204931dc in mozilla::layers::CompositorVsyncScheduler::ComposeToTarget (this=this@entry=0x7f49e108b000, aTarget=aTarget@entry=0x0, aRect=aRect@entry=0x0) at /build/firefox-trunk-fYuA0y/firefox-trunk-47.0~a1~hg20160125r281515/gfx/layers/ipc/CompositorParent.cpp:644 #15 0x00007f4a2049324d in mozilla::layers::CompositorVsyncScheduler::Composite (this=0x7f49e108b000, aVsyncTimestamp=...) at /build/firefox-trunk-fYuA0y/firefox-trunk-47.0~a1~hg20160125r281515/gfx/layers/ipc/CompositorParent.cpp:517 #16 0x00007f4a1fff47db in MessageLoop::RunTask (this=0x7f4a03dfed38, task=0x7f49db68af10) at /build/firefox-trunk-fYuA0y/firefox-trunk-47.0~a1~hg20160125r281515/ipc/chromium/src/base/message_loop.cc:364 #17 0x00007f4a1fff9456 in MessageLoop::DeferOrRunPendingTask (this=<optimized out>, pending_task=...) at /build/firefox-trunk-fYuA0y/firefox-trunk-47.0~a1~hg20160125r281515/ipc/chromium/src/base/message_loop.cc:372 #18 0x00007f4a1fff959a in MessageLoop::DoWork (this=0x7f4a03dfed38) at /build/firefox-trunk-fYuA0y/firefox-trunk-47.0~a1~hg20160125r281515/ipc/chromium/src/base/message_loop.cc:459 #19 0x00007f4a1fff49a8 in base::MessagePumpDefault::Run (this=0x7f4a03f31f70, delegate=0x7f4a03dfed38) at /build/firefox-trunk-fYuA0y/firefox-trunk-47.0~a1~hg20160125r281515/ipc/chromium/src/base/message_pump_default.cc:34 #20 0x00007f4a1fff4854 in MessageLoop::RunHandler (this=<optimized out>) at /build/firefox-trunk-fYuA0y/firefox-trunk-47.0~a1~hg20160125r281515/ipc/chromium/src/base/message_loop.cc:227 #21 MessageLoop::Run (this=this@entry=0x7f4a03dfed38) at /build/firefox-trunk-fYuA0y/firefox-trunk-47.0~a1~hg20160125r281515/ipc/chromium/src/base/message_loop.cc:201 #22 0x00007f4a1fffbd90 in base::Thread::ThreadMain (this=0x7f4a066ca650) at /build/firefox-trunk-fYuA0y/firefox-trunk-47.0~a1~hg20160125r281515/ipc/chromium/src/base/thread.cc:172 #23 0x00007f4a1fff980b in ThreadFunc (closure=<optimized out>) at /build/firefox-trunk-fYuA0y/firefox-trunk-47.0~a1~hg20160125r281515/ipc/chromium/src/base/platform_thread_posix.cc:36 #24 0x00007f4a2f98a6aa in start_thread (arg=0x7f4a03dff700) at pthread_create.c:333 #25 0x00007f4a2ec1ae9d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 (at least backtrace looks quite similar)
Sorry, should have checked first 1.11.1 seems to be working fine.
(In reply to Michel Dänzer from comment #11) > I can't seem to reproduce this (with radeonsi). Does it still happen with > libxcb 1.11.1 or newer, and current versions of Mesa and xserver? If yes, > can you provide a link reproducing the problem? I can't reproduce the problem either with newer versions, and I double-checked that LIBGL_DRI3_DISABLE isn't in the environment for any apps. But I'm not sure whether that's not DRI3 being disabled at the X level: Mar 01 15:35:25 classic /usr/libexec/gdm-x-session[1697]: (II) intel(0): [DRI2] Setup complete Mar 01 15:35:25 classic /usr/libexec/gdm-x-session[1697]: (II) intel(0): [DRI2] DRI driver: i965 Mar 01 15:35:25 classic /usr/libexec/gdm-x-session[1697]: (II) intel(0): [DRI2] VDPAU driver: va_gl Mar 01 15:35:25 classic /usr/libexec/gdm-x-session[1697]: (II) intel(0): direct rendering: DRI2 DRI3 enabled <snip> Mar 01 15:35:25 classic /usr/libexec/gdm-x-session[1697]: (II) GLX: Initialized DRI2 GL provider for screen 0 <snip>
Created attachment 122079 [details] attachment-15743-0.html ?I'm out of the office, returning Mon Mar. 7. I will have intermittent e-mail access so responses may be delayed. Regards, Tim
(In reply to Bastien Nocera from comment #14) > But I'm not sure whether that's not DRI3 being disabled at the X level: ... > Mar 01 15:35:25 classic /usr/libexec/gdm-x-session[1697]: (II) intel(0): > direct rendering: DRI2 DRI3 enabled DRI3 support is built into driver. > Mar 01 15:35:25 classic /usr/libexec/gdm-x-session[1697]: (II) GLX: > Initialized DRI2 GL provider for screen 0 Intel DDX defaults currently to DRI2, you can set DRI3 default in X config: -------------------------- Section "Device" Driver "Intel" Identifier "Intel" Option "DRI" "3" EndSection -------------------------- If you run the application with LIBGL_DEBUG=verbose, Mesa will tell which DRI version is used: -------------------------- $ LIBGL_DEBUG=verbose glxgears libGL: Using DRI3 for screen 0 --------------------------
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1447.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.