<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - glmark2-es2-wayland shortly freezes on some frames with egl_dri2 backend (Nouveau/GK20A)" href="https://bugs.freedesktop.org/show_bug.cgi?id=86690#c7">Comment # 7</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - glmark2-es2-wayland shortly freezes on some frames with egl_dri2 backend (Nouveau/GK20A)" href="https://bugs.freedesktop.org/show_bug.cgi?id=86690">bug 86690</a> from <a class="email" href="mailto:gnurou@gmail.com" title="Alexandre Courbot <gnurou@gmail.com>"> Alexandre Courbot</a> <pre>Some more input about this oddity. We are really waiting for fences here. During the freezes I can see the EGL client looping in nouveau_fence_wait(), and displaying the fence sequence and the highest signaled fence by the screen (screen->fence.sequence_ack) shows that sequence_ack < fence->sequence, indicating the GPU has not signaled this fence yet. I am starting to suspect a CPU scheduling issue here. Another very interesting phenomenon happens if I disable all but 1 CPU core: the issue becomes immediately visible (even worse than when perf top is running), for all Wayland EGL clients that set eglSwapInterval to 0. Wayland itself (or any DRM program for that instance) is still not affected, neither are Wayland clients not touching eglSwapInterval *until* they exit, at which point nouveau_fence_wait() will again endlessly loop on a fence. One way to release that fence is to trigger a draw event in another client. Then the screen's sequence_ack finally increases and the client goes through and exits. Doing the same in a client that set eglSwapInterval(0) allows it to draw a few frames, and then it blocks again. I suspect that some event in Wayland remains stuck somewhere, which leads to the EGL client to wait for a fence that Wayland fails to release when expected. Here is a gdb backtrace of weston-simple-egl when waiting for the fence: #0 0xb6d9298c in sched_yield () #1 0xb6a448ce in nouveau_fence_wait () #2 0xb6a45480 in nouveau_screen_fence_finish () #3 0xb69a351e in dri_flush () #4 0xb6fc399e in dri2_wl_swap_buffers_with_damage () #5 0xb6fc0f66 in dri2_swap_buffers_with_damage () #6 0xb6fb700c in eglSwapBuffersWithDamageEXT () #7 0x0000aa4a in redraw (data=0xbefff9e4, callback=0x0, time=0) #8 0x0000b254 in main (argc=2, argv=0xbefffc64) I guess the next step for me is to find how to get some output about Wayland events as they happen and see which one remains stuck.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>