[Xcb] _XReply stuck in xcb_wait_for_reply64

Fri Dec 2 00:08:13 UTC 2016

Googling a bit ( like a good engineer does, right ?  ) I found this
very similar problem:

https://lkml.org/lkml/2016/1/18/261

https://lists.freedesktop.org/archives/dri-devel/2016-January/099151.html

And then then some explanations here:

http://code.metager.de/source/history/linux/stable/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c

On Fri, Dec 2, 2016 at 1:27 AM, Marius Cirsta <mforce2 at gmail.com> wrote:
> #0  0x00007fc37f1673dd in poll () from /lib/libc.so.6
> #1  0x00007fc38311d1e0 in _xcb_conn_wait (c=c at entry=0x2584af0,
> cond=cond at entry=0x7ffe6ac997f0, vector=vector at entry=0x0,
> count=count at entry=0x0) at xcb_conn.c:479
> #2  0x00007fc38311ebdf in wait_for_reply (c=c at entry=0x2584af0,
> request=request at entry=65199, e=e at entry=0x7ffe6ac998b8) at xcb_in.c:516
> #3  0x00007fc38311ed31 in xcb_wait_for_reply64 (c=0x2584af0,
> request=65199, e=0x7ffe6ac998b8) at xcb_in.c:560
> #4  0x00007fc3833842e8 in _XReply (dpy=0x25838a0, rep=0x7ffe6ac99960,
> extra=0, discard=0) at xcb_io.c:596
> #5  0x00007fc37bf1b772 in DRI2GetBuffersWithFormat (dpy=0x25838a0,
> drawable=37748763, width=width at entry=0x4f54578,
> height=height at entry=0x4f5457c, attachments=0x7ffe6ac99af0, count=1,
> outCount=0x7ffe6ac99ad0) at dri2.c:491
> #6  0x00007fc37bf1ba97 in dri2GetBuffersWithFormat
> (driDrawable=<optimized out>, width=0x4f54578, height=0x4f5457c,
> attachments=<optimized out>, count=<optimized out>,
> out_count=0x7ffe6ac99ad0, loaderPrivate=0x5260100) at dri2_glx.c:894
> #7  0x00007fc358d6ac20 in dri2_drawable_get_buffers (count=<synthetic
> pointer>, atts=0x41f3338, drawable=0x438fbe0) at dri2.c:285
> #8  dri2_allocate_textures (ctx=0x25a7270, drawable=0x438fbe0,
> statts=0x41f3338, statts_count=2) at dri2.c:480
> #9  0x00007fc358d63d94 in dri_st_framebuffer_validate
> (stctx=<optimized out>, stfbi=<optimized out>, statts=0x41f3338,
> count=2, out=0x7ffe6ac99c60) at dri_drawable.c:83
> #10 0x00007fc358c3948c in st_framebuffer_validate (stfb=0x41f2ed0,
> st=st at entry=0x2d1f250) at state_tracker/st_manager.c:202
> #11 0x00007fc358c3a7de in st_api_make_current (stapi=<optimized out>,
> stctxi=0x2d1f250, stdrawi=0x438fbe0, streadi=0x438fbe0) at
> state_tracker/st_manager.c:781
> #12 0x00007fc358d636a1 in dri_make_current (cPriv=<optimized out>,
> driDrawPriv=0x4f54550, driReadPriv=0x4f54550) at dri_context.c:245
> #13 0x00007fc358d62606 in driBindContext (pcp=<optimized out>,
> pdp=<optimized out>, prp=<optimized out>) at dri_util.c:553
> #14 0x00007fc37bf1d41b in dri2_bind_context (context=0x25a4350,
> old=<optimized out>, draw=37748763, read=37748763) at dri2_glx.c:154
> #15 0x00007fc37bef7b67 in MakeContextCurrent (dpy=0x25838a0,
> draw=37748763, read=37748763, gc_user=0x25a4350) at glxcurrent.c:228
> #16 0x00007fc3849763d8 in ?? () from
> /usr/lib/qt5/plugins/xcbglintegrations/libqxcb-glx-integration.so
> #17 0x00007fc37fd63870 in QOpenGLContext::makeCurrent(QSurface*) ()
> from /usr/lib/libQt5Gui.so.5
> #18 0x00007fc3829d1860 in ?? () from /usr/lib/libQt5Quick.so.5
>
> Also mesa is at 13.0.2 and kernel is  4.8.10. Video card is an AMD
> HD5670 which as far as I know is not faulty ( doesn't show any signs
> of screen corruption or problems in Windows ).
>  I have to do some stuff to recreate this but I'm able to consistently
> recreate it.
>
> On Thu, Dec 1, 2016 at 3:42 AM, Michel Dänzer <michel at daenzer.net> wrote:
>> On 01/12/16 07:50 AM, Marius Cirsta wrote:
>>> Hello,
>>>
>>> I have a problem that came once I upgraded my Linux OS ( less known
>>> one called Fruglware OS ).
>>> For some reason with libxcb 1.12  libx11 1.6.4 I'm having this weird
>>> freeze in plasmashell:
>>>
>>> #0  0x00007fc2cf9cd3e1 in poll () from /lib/libc.so.6
>>> #1  0x00007fc2d39831e0 in _xcb_conn_wait (c=c at entry=0x117aaf0,
>>> cond=cond at entry=0x7fff869b5cd0, vector=vector at entry=0x0,
>>> count=count at entry=0x0) at xcb_conn.c:479
>>> #2  0x00007fc2d3984bdf in wait_for_reply (c=c at entry=0x117aaf0,
>>> request=request at entry=10682, e=e at entry=0x7fff869b5d98) at xcb_in.c:516
>>> #3  0x00007fc2d3984d31 in xcb_wait_for_reply64 (c=0x117aaf0,
>>> request=10682, e=0x7fff869b5d98) at xcb_in.c:560
>>> #4  0x00007fc2d3bea2e8 in _XReply (dpy=0x11798a0, rep=0x7fff869b5e40,
>>> extra=0, discard=0) at xcb_io.c:596
>>> #5  0x00007fc2cc781cd2 in ?? () from /usr/lib/libGL.so.1
>>> #6  0x00007fc2cc781ff7 in ?? () from /usr/lib/libGL.so.1
>>> #7  0x00007fc2216f9239 in ?? () from /usr/lib/dri/r600_dri.so
>>> #8  0x00007fc2216f3ab4 in ?? () from /usr/lib/dri/r600_dri.so
>>> #9  0x00007fc2215dd92c in ?? () from /usr/lib/dri/r600_dri.so
>>> #10 0x00007fc2215de84c in ?? () from /usr/lib/dri/r600_dri.so
>>> #11 0x00007fc22158a67b in ?? () from /usr/lib/dri/r600_dri.so
>>> #12 0x00007fc221592eb4 in ?? () from /usr/lib/dri/r600_dri.so
>>
>> Please get a backtrace with debugging symbols available for
>> /usr/lib/libGL.so.1 and /usr/lib/dri/r600_dri.so as well.
>>
>>
>> --
>> Earthling Michel Dänzer               |               http://www.amd.com
>> Libre software enthusiast             |             Mesa and X developer