[Xcb] _XReply stuck in xcb_wait_for_reply64

Fri Dec 2 00:41:30 UTC 2016

 Sorry for spamming here but I think I found my bug indeed:

https://bugs.freedesktop.org/show_bug.cgi?id=98645

Funny thing is that I have an X99 chipset too, I actually have this
motherboard:  http://www.asrock.com/mb/Intel/X99%20Extreme4/?cat=Specifications

I only have a single screen though and it's all it takes to reproduce
this apparently.

I think maybe we should continue the discussion on that bug, right ?
I'll also try with radeon.msi=0 but need to do it tomorrow.

These problems only started appearing recently though so I suspect
maybe a kernel update or something. I'll could try with an older
version of the kernel I suppose and maybe even bisect this.

Thanks.

On Fri, Dec 2, 2016 at 2:08 AM, Marius Cirsta <mforce2 at gmail.com> wrote:
> 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