343551 2015-01-30 02:26:51 +0000 Kwin hangs, stops drawing the screen and starts using 100% cpu inside nvidia-glcore after modifying compositing settings 2015-06-05 19:13:08 +0000 1 1 4 Plasma kwin scene-opengl unspecified unspecified Linux RESOLVED FIXED https://bugs.kde.org/show_bug.cgi?id=346116 https://bugs.kde.org/show_bug.cgi?id=348753 drkonqi NOR normal --- 0 bladud kwin-bugs-null adloconwy+kdebug auxsvr bladud sergio.callegari simonandric5 sombragris 1de1e80d5077157fc25503c4699969c57929795d 5.3 0 oldest_to_newest 1495788 0 bladud 2015-01-30 02:26:51 +0000 Application: systemsettings5 (5.2.0) Qt Version: 5.4.0 Operating System: Linux 3.18.4-1-ARCH x86_64 Distribution: "Arch Linux" -- Information about the crash: - What I was doing when the application crashed: 1. Open system settings to the compositor page. 2. Examine page for a few seconds 3. hit the button to return to overview - overview displays, but crash occurs shortly afterwards. - Custom settings of the application: I am using the nvidia binary driver, v304.125. rendering backend is opengl v3.1 in system settings opengl interface is glx scale method is 'accurate' The crash can be reproduced every time. -- Backtrace: Application: System Settings (systemsettings5), signal: Segmentation fault Using host libthread_db library "/usr/lib/libthread_db.so.1". [Current thread is 1 (Thread 0x7faf0ec277c0 (LWP 9063))] Thread 5 (Thread 0x7faefcc35700 (LWP 9064)): #0 0x00007faf0b3a344d in poll () from /usr/lib/libc.so.6 #1 0x00007faf098539f2 in ?? () from /usr/lib/libxcb.so.1 #2 0x00007faf0985556f in xcb_wait_for_event () from /usr/lib/libxcb.so.1 #3 0x00007faeff6093f9 in ?? () from /usr/lib/qt/plugins/platforms/libqxcb.so #4 0x00007faf0ba195ee in ?? () from /usr/lib/libQt5Core.so.5 #5 0x00007faf08150754 in ?? () from /usr/lib/libGL.so.1 #6 0x00007faf08fce314 in start_thread () from /usr/lib/libpthread.so.0 #7 0x00007faf0b3ac24d in clone () from /usr/lib/libc.so.6 Thread 4 (Thread 0x7faeeea71700 (LWP 9080)): #0 0x00007faf0ec094c0 in update_get_addr () from /lib64/ld-linux-x86-64.so.2 #1 0x00007faf0ba184f2 in ?? () from /usr/lib/libQt5Core.so.5 #2 0x00007faf0bc5a60a in ?? () from /usr/lib/libQt5Core.so.5 #3 0x00007faf08ab121d in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0 #4 0x00007faf08ab1bbb in ?? () from /usr/lib/libglib-2.0.so.0 #5 0x00007faf08ab1dac in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #6 0x00007faf0bc5b08c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #7 0x00007faf0bc01532 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #8 0x00007faf0ba14664 in QThread::exec() () from /usr/lib/libQt5Core.so.5 #9 0x00007faf0ba195ee in ?? () from /usr/lib/libQt5Core.so.5 #10 0x00007faf08150754 in ?? () from /usr/lib/libGL.so.1 #11 0x00007faf08fce314 in start_thread () from /usr/lib/libpthread.so.0 #12 0x00007faf0b3ac24d in clone () from /usr/lib/libc.so.6 Thread 3 (Thread 0x7faeda3df700 (LWP 9180)): #0 0x00007faf0b3a344d in poll () from /usr/lib/libc.so.6 #1 0x00007faf08ab1c94 in ?? () from /usr/lib/libglib-2.0.so.0 #2 0x00007faf08ab2022 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #3 0x00007faee5325cf6 in ?? () from /usr/lib/libgio-2.0.so.0 #4 0x00007faf08ad85f5 in ?? () from /usr/lib/libglib-2.0.so.0 #5 0x00007faf08150754 in ?? () from /usr/lib/libGL.so.1 #6 0x00007faf08fce314 in start_thread () from /usr/lib/libpthread.so.0 #7 0x00007faf0b3ac24d in clone () from /usr/lib/libc.so.6 Thread 2 (Thread 0x7faedb5ee700 (LWP 9380)): #0 0x00007faf0b3a344d in poll () from /usr/lib/libc.so.6 #1 0x00007faece53570c in ?? () from /usr/lib/libusb-1.0.so.0 #2 0x00007faf08fce314 in start_thread () from /usr/lib/libpthread.so.0 #3 0x00007faf0b3ac24d in clone () from /usr/lib/libc.so.6 Thread 1 (Thread 0x7faf0ec277c0 (LWP 9063)): [KCrash Handler] #5 0x00007faef1492ab0 in QQuickWindow::maybeUpdate() () from /usr/lib/libQt5Quick.so.5 #6 0x00007faef147ed08 in QQuickItemPrivate::dirty(QQuickItemPrivate::DirtyType) () from /usr/lib/libQt5Quick.so.5 #7 0x00007faef1488e85 in ?? () from /usr/lib/libQt5Quick.so.5 #8 0x00007faf0bc344ba in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5 #9 0x00007faef1487a0b in QQuickItem::event(QEvent*) () from /usr/lib/libQt5Quick.so.5 #10 0x00007faf0d0a1d8c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #11 0x00007faf0d0a7370 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #12 0x00007faf0bc03a9b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5 #13 0x00007faf0bc05adb in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQt5Core.so.5 #14 0x00007faf0bc5ac83 in ?? () from /usr/lib/libQt5Core.so.5 #15 0x00007faf08ab1a0d in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #16 0x00007faf08ab1cf8 in ?? () from /usr/lib/libglib-2.0.so.0 #17 0x00007faf08ab1dac in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #18 0x00007faf0bc5b077 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #19 0x00007faf0bc01532 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #20 0x00007faf0bc08f0c in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5 #21 0x000000000040e64c in main () Reported using DrKonqi 1495990 1 thomas.luebking 2015-01-30 22:46:39 +0000 *** This bug has been marked as a duplicate of bug 343543 *** 1495995 2 thomas.luebking 2015-01-30 23:01:51 +0000 Have you been in the "compositing" (where you can change the backend etc.) or the "effects" (where you can swith on/off wobbly windows etc.) kcm? 1496017 3 bladud 2015-01-31 00:42:41 +0000 The compositing, where you can change the backend. In plasma 5.1 the crash was also present, but took down kwin as well. 1496024 4 bladud 2015-01-31 01:15:55 +0000 I spoke too soon - actually changing the settings causes kwin and kded5 to freeze and take 100% of a cpu each. 1496026 5 thomas.luebking 2015-01-31 01:22:38 +0000 Changing what settings? There's a reported eventloop recursion for kwin in the tabbox, see bug #340294 There's also a bug report for kded5, seems caused by the powerdevil module, see bug #337674 Neither would be related to this crash - it's something in QML - apparently rather the "new" QML context then the closed one (as the compositing kcm doesn't use it) But I've not yet checked whether the overview really uses QML. 1496029 6 bladud 2015-01-31 01:37:46 +0000 Just now it crashed checking the box labelled "skip compositing for full-screen windows". I suspect that changing the backend or any of the other compositing settings would also crash (as in plasma 5.1). If you like I can check whether it still crashes with nouveau. 1496031 7 thomas.luebking 2015-01-31 01:39:34 +0000 *systemsettings* crashed with *that* backtrace for altering a kwin setting?? 1496034 8 bladud 2015-01-31 01:51:58 +0000 Sorry, I was imprecise. systemsettings crashes with this backtrace when exiting the compositing kcm after not changing a setting. If I do change a setting in the compositing kcm, both kwin and kded5 hang. This may involve a crash, but it may not - it hangs and there is no backtrace window. 1496035 9 bladud 2015-01-31 01:54:29 +0000 In fact when kwin hangs there is no crash at all, at least not one which creates a coredump. 1496039 10 bladud 2015-01-31 02:27:00 +0000 When kwin hangs with 100% cpu usage, I obtained a backtrace by attaching gdb to the hung process. The top four lines looked like: sched_yield /usr/lib/libc6 ??? /usr/lib/libnvidia-glcore.so.304.125 ??? /usr/lib/libnvidia-glcore.so.304.125 ??? /usr/lib/libnvidia-glcore.so.304.125 and below that was kwin, which doesn't have symbols at the moment. Note that I have enabled Triple buffering in xorg.conf as suggested in https://bugs.kde.org/show_bug.cgi?id=322060 If I export __GL_YIELD="USLEEP" instead, the top lines in the backtrace are nanosleep and usleep. 1496040 11 90827 bladud 2015-01-31 02:59:31 +0000 Created attachment 90827 Backtrace when kwin is stuck and screen is not drawing 1496041 12 90828 bladud 2015-01-31 03:16:05 +0000 Created attachment 90828 Patch to 'fix' hang on deletion by not deleting object This patch fixes the kwin hang for me, at the cost of leaking memory. It seems that this must be a bug in the nvidia driver? I found this by googling: https://www.opengl.org/discussion_boards/showthread.php/171741-NVIDIA-bug-in-glDeleteSync 1496042 13 bladud 2015-01-31 03:19:21 +0000 Re-opened and updated title, since I realise there are two different bugs here. 1496141 14 thomas.luebking 2015-01-31 18:42:40 +0000 Would either of those patches do as well? (1st one preferably) diff --git a/scene_opengl.cpp b/scene_opengl.cpp index 7584dd5..486af4d 100644 --- a/scene_opengl.cpp +++ b/scene_opengl.cpp @@ -120,6 +120,8 @@ SyncObject::SyncObject() SyncObject::~SyncObject() { + if (m_state == Waiting) + glFinish(); xcb_sync_destroy_fence(connection(), m_fence); glDeleteSync(m_sync); ----------------------------------- diff --git a/scene_opengl.cpp b/scene_opengl.cpp index 7584dd5..e095157 100644 --- a/scene_opengl.cpp +++ b/scene_opengl.cpp @@ -412,6 +412,7 @@ SceneOpenGL::~SceneOpenGL() // do cleanup after initBuffer() SceneOpenGL::EffectFrame::cleanup(); if (init_ok) { + glFinish(); delete m_syncManager; // backend might be still needed for a different scene 1496143 15 bladud 2015-01-31 19:04:15 +0000 I tried both patches. Unfortunately they don't make a difference. 1496144 16 bladud 2015-01-31 19:04:52 +0000 (I tried both in turn, not both at once) 1496201 17 thomas.luebking 2015-01-31 23:54:01 +0000 Ok, let's be more explicit on our needs ;-) loki:/src/KDE4/kwin/> git diff scene_opengl.cpp diff --git a/scene_opengl.cpp b/scene_opengl.cpp index 7584dd5..08256be 100644 --- a/scene_opengl.cpp +++ b/scene_opengl.cpp @@ -120,6 +120,8 @@ SyncObject::SyncObject() SyncObject::~SyncObject() { +// if (m_state == Waiting) + glFinish(); xcb_sync_destroy_fence(connection(), m_fence); glDeleteSync(m_sync); @@ -412,6 +414,7 @@ SceneOpenGL::~SceneOpenGL() // do cleanup after initBuffer() SceneOpenGL::EffectFrame::cleanup(); if (init_ok) { + m_backend->makeCurrent(); delete m_syncManager; // backend might be still needed for a different scene 1496220 18 bladud 2015-02-01 04:41:13 +0000 Hm. That didn't help either (strangely). 1496396 19 thomas.luebking 2015-02-02 00:21:47 +0000 *grrrr* Maybe we can trick it through the swap interval.... => Does this also happen if you set the tearing prevention to "none"? 1496416 20 bladud 2015-02-02 05:14:17 +0000 If I set tearing prevention to 'none' the problem is fixed! 1496520 21 90873 thomas.luebking 2015-02-02 14:45:11 +0000 Created attachment 90873 stop stap control before deleting sync objects Ok, attached is a larger (and untested!) patch. 1496547 22 bladud 2015-02-02 16:50:21 +0000 Ah, apologies. Turning off tearing prevention doesn't actually make a difference; I was running with the patch from comment 12 by accident. I also tried the patch from comment 21 and it didn't fix it either. Thanks for your help 1497083 23 thomas.luebking 2015-02-04 14:30:26 +0000 *** Bug 343773 has been marked as a duplicate of this bug. *** 1497092 24 sombragris 2015-02-04 15:24:11 +0000 Well, I filed a bug report for a different use case (bug 343773) and it has been marked as duplicate of this bug. In my case, Kwin started eating 100% CPU and not drawing anything. Killing kwin_x11 and setting the rendering engine to XRender gave me an usable desktop (after a restart). This is a regression, since the bug was not present in the latest stable kwin from Plasma 4. 1497093 25 sombragris 2015-02-04 15:24:55 +0000 I wish to add that I am also using the nVidia 304.125 proprietary legacy driver. 1498945 26 fredrik 2015-02-09 18:11:35 +0000 The backtrace shows that the driver is busy-waiting for something in glDeleteSync(). What do you suppose that function could be waiting for? 1498996 27 thomas.luebking 2015-02-09 22:24:11 +0000 (In reply to Fredrik Höglund from comment #26) > What do you suppose that function could be waiting for? You believe a nice "xcb_flush(connection());" could do? 1499904 28 bladud 2015-02-14 17:45:20 +0000 Sorry, that didn't work either [xcb_flush(connection()); just before the glDeleteSync] I also tried it in conjunction with the glFinish patch above 1499916 29 fredrik 2015-02-14 18:52:01 +0000 (In reply to Thomas Lübking from comment #27) > (In reply to Fredrik Höglund from comment #26) > > What do you suppose that function could be waiting for? > > You believe a nice "xcb_flush(connection());" could do? You didn't answer my question. 1499948 30 thomas.luebking 2015-02-14 20:38:02 +0000 (In reply to Fredrik Höglund from comment #29) > You didn't answer my question. I thought I did ;-) Since we already ruled out waiting for the retrace and it's apparently not the fence, i could only imagine it's waiting to get the context active - but I've no favorite supposition (or had) The diver is not supposed to block here, so it could be any kind of (inc. internal) mutex. 1500003 31 91085 bladud 2015-02-15 04:45:00 +0000 Created attachment 91085 Another patch to fix the hang by manually triggering the xcb fence. The hang occurs when the sync is in the Ready or Resetting state. It seems that nvidia doesn't like it if the gl sync is deleted or waited on before the xcb fence has been triggered. This patch fixes it - there is no theory behind this, just trial and error. It also seems to me that if wait() is called sufficiently quickly after trigger() there will also be a hang. 1500242 32 fredrik 2015-02-16 00:27:53 +0000 (In reply to Simeon Bird from comment #31) > Created attachment 91085 [details] > Another patch to fix the hang by manually triggering the xcb fence. > > The hang occurs when the sync is in the Ready or Resetting state. It seems > that nvidia doesn't like it if the gl sync is deleted or waited on before > the xcb fence has been triggered. > > This patch fixes it - there is no theory behind this, just trial and error. > It also seems to me that if wait() is called sufficiently quickly after > trigger() there will also be a hang. Your patch is absolutely correct, but some of the comments in the code are not. What glDeleteSync() is clearly waiting for is for the fence to become signaled, and that is never going to happen unless kwin tells the X server to trigger it. So it's not really correct to say that we need to manually trigger the fence; it's not something that can happen automatically. It would be a very serious bug if it ever did. The comment above xcb_flush() is also not exactly correct. If the xcb_flush() call is left out, glDeleteSync() will wait for the fence to become signaled, but the trigger request will be stuck in the output buffer and never sent to the X server. So glDeleteSync() ends up waiting indefinitely. There is no need to call wait() before deleting the fence. The purpose of wait() is to prevent the GPU from executing future draw commands before the fence is signaled, and that's not relevant here. There may be a similar hazard between calling wait() and glDeleteSync() without a glFlush() in-between as with calling trigger() and glDeleteSync() without an xcb_flush() in-between. If you want to make sure that the fence is signaled before you call glDeleteSync(), you should call finish() instead of wait(). 1500273 33 bladud 2015-02-16 05:50:54 +0000 > Your patch is absolutely correct, but some of the comments in the code are > not. Ok, I'll update the comments and post a new version. Incidentally, is this actually an nvidia bug? ie, does the standard call for glDeleteSync not to block? If the answer is yes, should the patch be made conditional on the nvidia driver somehow? > There is no need to call wait() before deleting the fence. The purpose of > wait() is to prevent the GPU from executing future draw commands before the > fence is signaled, and that's not relevant here. What I was worried about was in some other case - if trigger() is called and then insertWait() is called immediately afterwards as part of the normal draw routines. This would be a classic race condition and would lead to an occasional unrepeatable hang. But maybe it isn't possible for this to happen without something equivalent to xcb_flush? > There may be a similar > hazard between calling wait() and glDeleteSync() without a glFlush() > in-between as with calling trigger() and glDeleteSync() without an > xcb_flush() in-between. If you want to make sure that the fence is signaled > before you call glDeleteSync(), you should call finish() instead of wait(). That's actually fine (I checked when debugging) 1500791 34 fredrik 2015-02-17 23:37:28 +0000 (In reply to Simeon Bird from comment #33) > > Your patch is absolutely correct, but some of the comments in the code are > > not. > > Ok, I'll update the comments and post a new version. Incidentally, is this > actually an nvidia bug? > ie, does the standard call for glDeleteSync not to block? If the answer is > yes, should the patch > be made conditional on the nvidia driver somehow? I would say that the OpenGL specification strongly implies that glDeleteSync should not block, but it doesn't explicitly say that it's not allowed to. My guess is that there's some limitation that prevents the NVIDIA driver from knowing when it's safe to delete the sync object without blocking on the fence. Triggering the fence before deleting it is not a big deal though, so I wouldn't bother with making it conditional on the NVIDIA driver. It's the only driver that implements the GL_EXT_x11_sync_object extension anyway. > > There is no need to call wait() before deleting the fence. The purpose of > > wait() is to prevent the GPU from executing future draw commands before the > > fence is signaled, and that's not relevant here. > > What I was worried about was in some other case - if trigger() is called and > then insertWait() is called immediately afterwards as part of the normal > draw routines. This would be a classic race condition and would lead to an > occasional unrepeatable hang. But maybe it isn't possible for this to happen > without something equivalent to xcb_flush? That's a good question. It shouldn't matter if the command buffer that signals the fence is submitted after the command buffer that waits for it, as long as both command buffers are able to execute concurrently. This is of course hardware dependent, but all current NVIDIA GPU's should have multiple hardware contexts. The best way to test this is probably to call glWaitSync() and glFlush(), and then tell the X server to trigger the fence. If that results in a GPU hang, we need to make sure that the X server has processed the trigger request before we call glWaitSync(). It might be a good idea to do that anyway for the sake of robustness. 1501090 35 thomas.luebking 2015-02-19 14:21:03 +0000 (In reply to Fredrik Höglund from comment #32) > What glDeleteSync() is clearly waiting for is for the fence to become signaled (excuse my stupidity) Is this any "clearly" beyond hindsight? From out of all options, I considered this to be the least reasonable one (would that mean the driver is in pre-emptive waiting condition - and what would be the runtime implications for windows that never trigger the fence?) 1501305 36 fredrik 2015-02-20 17:51:21 +0000 (In reply to Thomas Lübking from comment #35) > (In reply to Fredrik Höglund from comment #32) > > What glDeleteSync() is clearly waiting for is for the fence to become signaled > > (excuse my stupidity) > Is this any "clearly" beyond hindsight? > From out of all options, I considered this to be the least reasonable one A fence is a synchronization primitive that is inserted in the command stream so that you can wait for it and know that all prior commands have completed. So when the function that deletes the associated sync object waits indefinitely for something, my first thought is that it is waiting for the fence. Especially when you consider that at least some of these sync objects are in an unsignaled state, and no fence command has been set in the command stream that will signal them. That Simeon's patch fixes the problem proves the theory. > (would that mean the driver is in pre-emptive waiting condition - and what > would be the runtime implications for windows that never trigger the fence?) Windows don't trigger fences. The fences are triggered from Compositor::performCompositing() immediately after fetching and resetting the damage region, so we can know that the damage has landed in the window textures before we render them. When we are about to render the first damaged window, we insert a command to wait for the fence. If there are no damaged windows, we don't trigger or wait for any fences. 1502804 37 91353 bladud 2015-02-28 22:46:38 +0000 Created attachment 91353 Updated patch to fix hang by triggering fence Ok, here is a patch with updated comments. How does this get into kwin? Should I open a review board, or do you just take it? 1507964 38 auxsvr 2015-03-29 10:22:38 +0000 Under similar conditions I get the following backtrace while kwin_x11 uses 100% CPU: #0 0x00007f5a77d62a17 in sched_yield () at /lib64/libc.so.6 #1 0x00007f5a671d5e4e in () at /usr/lib64/libnvidia-glcore.so.304.125 #2 0x00007f5a671d68f6 in () at /usr/lib64/libnvidia-glcore.so.304.125 #3 0x00007f5a66fb5c2f in () at /usr/lib64/libnvidia-glcore.so.304.125 #4 0x00007f5a7795d25e in KWin::SyncObject::~SyncObject() (this=0xbd7ef8, __in_chrg=<optimized out>) at /usr/src/debug/kwin-5.2.2/scene_opengl.cpp:124 #5 0x00007f5a779612cc in KWin::SceneOpenGL::~SceneOpenGL() (this=0xbd7ee0, __in_chrg=<optimized out>) at /usr/include/c++/4.8/array:81 #6 0x00007f5a779612cc in KWin::SceneOpenGL::~SceneOpenGL() (this=0xbd7ee0, __in_chrg=<optimized out>) at /usr/src/debug/kwin-5.2.2/scene_opengl.cpp:242 #7 0x00007f5a779612cc in KWin::SceneOpenGL::~SceneOpenGL() (this=0xba53a0, __in_chrg=<optimized out>) at /usr/src/debug/kwin-5.2.2/scene_opengl.cpp:415 #8 0x00007f5a77961359 in KWin::SceneOpenGL2::~SceneOpenGL2() (this=0xba53a0, __in_chrg=<optimized out>) at /usr/src/debug/kwin-5.2.2/scene_opengl.cpp:966 #9 0x00007f5a77948657 in KWin::Compositor::finish() (this=this@entry=0x8e8490) at /usr/src/debug/kwin-5.2.2/composite.cpp:337 #10 0x00007f5a77948c04 in KWin::Compositor::suspend(KWin::Compositor::SuspendReason) (this=0x8e8490, reason=<optimized out>) at /usr/src/debug/kwin-5.2.2/composite.cpp:508 #11 0x00007f5a75e4503f in QMetaObject::activate(QObject*, int, int, void**) (a=0x7fff200490b0, r=0x8a58c0, this=0xcf0ea0) at ../../src/corelib/kernel/qobject_impl.h:124 #12 0x00007f5a75e4503f in QMetaObject::activate(QObject*, int, int, void**) (sender=0xc338a0, signalOffset=<optimized out>, local_signal_index=<optimized out>, argv=0x7fff200490b0) at kernel/qobject.cpp:3702 #13 0x00007f5a76acc662 in QAction::triggered(bool) () at /usr/lib64/libQt5Widgets.so.5 #14 0x00007f5a76aceb48 in QAction::activate(QAction::ActionEvent) () at /usr/lib64/libQt5Widgets.so.5 Should I file a new report? 1507965 39 thomas.luebking 2015-03-29 10:27:21 +0000 (In reply to auxsvr from comment #38) > Under similar conditions I get the following backtrace while kwin_x11 uses > 100% CPU: With 5.3? Otherwise it's very most likely this bug and should be fixed/worked around in 5.3 1507974 40 auxsvr 2015-03-29 11:57:01 +0000 I'm sorry, I didn't see that 5.3 fixes this. I'm on 5.2.2. 1515397 41 sergio.callegari 2015-05-02 14:27:04 +0000 Can someone clarify if this is expected to be fixed in 5.3? I have just upgraded my system to kubuntu 15.04 that uses plasma 5 and lets either 5.2 (default) or 5.3 (via a dedicated repository) be installed. Unfortunately, with neither of them I succeed in using kwin_x11 with opengl glx together with a system with a nvidia geoforce 7025 / nforce 630 with the nvidia 304 legacy driver that reports opengl 2.1 on this hardware. 1515398 42 sergio.callegari 2015-05-02 14:27:54 +0000 Can someone clarify if this is expected to be fixed in 5.3? I have just upgraded my system to kubuntu 15.04 that uses plasma 5 and lets either 5.2 (default) or 5.3 (via a dedicated repository) be installed. Unfortunately, with neither of them I succeed in using kwin_x11 with opengl glx together with a system with a nvidia geoforce 7025 / nforce 630 with the nvidia 304 legacy driver that reports opengl 2.1 on this hardware. 1515406 43 bladud 2015-05-02 15:11:18 +0000 It is fixed for me on 5.3 - same driver and glx 1515413 44 thomas.luebking 2015-05-02 15:58:01 +0000 > with neither of them I succeed in using kwin_x11 with opengl glx Are you sure it's for this particular bug? This one's caused by a hanging fence sync and apparently triggered by invoking the config module. It should be work-a-roundable by export KWIN_EXPLICIT_SYNC=0; kwin_x11 --replace & 1515875 45 sergio.callegari 2015-05-03 23:16:37 +0000 Tried... seems to work with the workaround on 5.3. So I guess it is not fixed in 5.3, or at least not in Kubuntu's 5.3... 1515938 46 thomas.luebking 2015-05-04 09:14:19 +0000 Do you get 100% cpu load instead? If so, can you gdb into kwin and check where it hangs? If not, the sync fences may cause an "unrelated" problem for you. 1515955 47 sergio.callegari 2015-05-04 11:22:35 +0000 After the utopic->vivid upgrade, I get the machine in over 60% iowait, 0 cpu load, but I do not think this is related. Possibly it is another (and more serious) issue with ubuntu vivid. When kwin is hung, continuously switching to a virtual console and back to the X11 screen with ALT+FN lets one do operations in steps... The machine is using the KDE 5.3 ppa right now. Setting the environment variables makes it almost usable (apart from the other issues mentioned above, like the 60% iowait and io-related processes getting stuck). In any case, the machine is now off and I am reinstalling it as trusty with kde 4 or mint with cinnamon soon because I cannot afford keeping it off, so unfortunately I will not be able to do more tests or provide a lot of further information. It is a pity, kubuntu decided to make so many changes at the same time in this upgrade, because I really do not have not enough time right now to try decoupling the problems. 1517139 48 adloconwy+kdebug 2015-05-09 01:33:29 +0000 This bug still seems to exist in Plasma 5.3 on Arch Linux. 1524231 49 thomas.luebking 2015-06-05 19:13:08 +0000 Let's track remaining issues with this feature and the nvidia legacy driver in bug #348753 It would be great if somebody encountering this could gdb into kwin_x11 and check where it's hanging. Usual suspects would glDeleteSync calls in libkwineffects/kwinglutils.cpp 90827 2015-01-31 02:59:31 +0000 2015-01-31 02:59:31 +0000 Backtrace when kwin is stuck and screen is not drawing gdb.txt text/plain 3405 bladud IzAgIDB4MDAwMDdmNzVlYWY5MTIzNyBpbiBzY2hlZF95aWVsZCAoKSBmcm9tIC91c3IvbGliL2xp YmMuc28uNgojMSAgMHgwMDAwN2Y3NWRiMmZlZTRlIGluID8/ICgpIGZyb20gL3Vzci9saWIvbGli bnZpZGlhLWdsY29yZS5zby4zMDQuMTI1CiMyICAweDAwMDA3Zjc1ZGIyZmY4ZjYgaW4gPz8gKCkg ZnJvbSAvdXNyL2xpYi9saWJudmlkaWEtZ2xjb3JlLnNvLjMwNC4xMjUKIzMgIDB4MDAwMDdmNzVk YjBkZWMyZiBpbiA/PyAoKSBmcm9tIC91c3IvbGliL2xpYm52aWRpYS1nbGNvcmUuc28uMzA0LjEy NQojNCAgMHgwMDAwN2Y3NWVhYjY4NWFlIGluIEtXaW46OlN5bmNPYmplY3Q6On5TeW5jT2JqZWN0 ICh0aGlzPTB4MWVmZjEzOCwgCiAgICBfX2luX2Nocmc9PG9wdGltaXplZCBvdXQ+KQogICAgYXQg L2hvbWUvc3BiNDEvYnVpbGQva3dpbi90cnVuay9zcmMva3dpbi01LjIuMC4xL3NjZW5lX29wZW5n bC5jcHA6MTI0CiM1ICAweDAwMDA3Zjc1ZWFiNmM4ZmMgaW4gfmFycmF5ICh0aGlzPTB4MWVmZjEy MCwgX19pbl9jaHJnPTxvcHRpbWl6ZWQgb3V0PikKICAgIGF0IC91c3IvaW5jbHVkZS9jKysvNC45 LjIvYXJyYXk6ODEKIzYgIH5TeW5jTWFuYWdlciAodGhpcz0weDFlZmYxMjAsIF9faW5fY2hyZz08 b3B0aW1pemVkIG91dD4pCiAgICBhdCAvaG9tZS9zcGI0MS9idWlsZC9rd2luL3RydW5rL3NyYy9r d2luLTUuMi4wLjEvc2NlbmVfb3BlbmdsLmNwcDoyNDIKIzcgIEtXaW46OlNjZW5lT3BlbkdMOjp+ U2NlbmVPcGVuR0wgKHRoaXM9MHgxZjA0M2IwLCBfX2luX2Nocmc9PG9wdGltaXplZCBvdXQ+KQog ICAgYXQgL2hvbWUvc3BiNDEvYnVpbGQva3dpbi90cnVuay9zcmMva3dpbi01LjIuMC4xL3NjZW5l X29wZW5nbC5jcHA6NDE1CiM4ICAweDAwMDA3Zjc1ZWFiNmM5N2QgaW4gS1dpbjo6U2NlbmVPcGVu R0wyOjp+U2NlbmVPcGVuR0wyICgKICAgIHRoaXM9PG9wdGltaXplZCBvdXQ+LCBfX2luX2Nocmc9 PG9wdGltaXplZCBvdXQ+KQogICAgYXQgL2hvbWUvc3BiNDEvYnVpbGQva3dpbi90cnVuay9zcmMv a3dpbi01LjIuMC4xL3NjZW5lX29wZW5nbC5jcHA6OTY0CiM5ICAweDAwMDA3Zjc1ZWFiNmM5ODkg aW4gS1dpbjo6U2NlbmVPcGVuR0wyOjp+U2NlbmVPcGVuR0wyICh0aGlzPTB4MWYwNDNiMCwgCiAg ICBfX2luX2Nocmc9PG9wdGltaXplZCBvdXQ+KQogICAgYXQgL2hvbWUvc3BiNDEvYnVpbGQva3dp bi90cnVuay9zcmMva3dpbi01LjIuMC4xL3NjZW5lX29wZW5nbC5jcHA6OTY2CiMxMCAweDAwMDA3 Zjc1ZWFiNTIzZjQgaW4gS1dpbjo6Q29tcG9zaXRvcjo6ZmluaXNoICh0aGlzPXRoaXNAZW50cnk9 MHgxZTc4N2QwKQogICAgYXQgL2hvbWUvc3BiNDEvYnVpbGQva3dpbi90cnVuay9zcmMva3dpbi01 LjIuMC4xL2NvbXBvc2l0ZS5jcHA6MzM3CiMxMSAweDAwMDA3Zjc1ZWFiNTI4ZGYgaW4gS1dpbjo6 Q29tcG9zaXRvcjo6c2xvdFJlaW5pdGlhbGl6ZSAodGhpcz0weDFlNzg3ZDApCiAgICBhdCAvaG9t ZS9zcGI0MS9idWlsZC9rd2luL3RydW5rL3NyYy9rd2luLTUuMi4wLjEvY29tcG9zaXRlLmNwcDo0 MzYKIzEyIDB4MDAwMDdmNzVlYWMxNTgyNSBpbiBLV2luOjpDb21wb3NpdG9yOjpxdF9zdGF0aWNf bWV0YWNhbGwgKAogICAgX289PG9wdGltaXplZCBvdXQ+LCBfYz08b3B0aW1pemVkIG91dD4sIF9p ZD08b3B0aW1pemVkIG91dD4sIAogICAgX2E9PG9wdGltaXplZCBvdXQ+KQogICAgYXQgL2hvbWUv c3BiNDEvYnVpbGQva3dpbi90cnVuay9zcmMvYnVpbGQvbW9jX2NvbXBvc2l0ZS5jcHA6MjUzCiMx MyAweDAwMDA3Zjc1ZWFjMjI2OTMgaW4gS1dpbjo6Q29tcG9zaXRvcjo6cXRfbWV0YWNhbGwgKHRo aXM9MHgxZTc4N2QwLCAKICAgIF9jPVFNZXRhT2JqZWN0OjpJbnZva2VNZXRhTWV0aG9kLCBfaWQ9 NiwgX2E9MHg3ZmZmZWI2ODViZTApCiAgICBhdCAvaG9tZS9zcGI0MS9idWlsZC9rd2luL3RydW5r L3NyYy9idWlsZC9tb2NfY29tcG9zaXRlLmNwcDozMTcKIzE0IDB4MDAwMDdmNzVlYjVjMzQyNyBp biA/PyAoKSBmcm9tIC91c3IvbGliL2xpYlF0NURCdXMuc28uNQojMTUgMHgwMDAwN2Y3NWU5N2Yy NGJhIGluIFFPYmplY3Q6OmV2ZW50KFFFdmVudCopICgpCiAgIGZyb20gL3Vzci9saWIvbGliUXQ1 Q29yZS5zby41CiMxNiAweDAwMDA3Zjc1ZWEwOWZkOGMgaW4gUUFwcGxpY2F0aW9uUHJpdmF0ZTo6 bm90aWZ5X2hlbHBlcihRT2JqZWN0KiwgUUV2ZW50KikKICAgICgpIGZyb20gL3Vzci9saWIvbGli UXQ1V2lkZ2V0cy5zby41CiMxNyAweDAwMDA3Zjc1ZWEwYTUzNzAgaW4gUUFwcGxpY2F0aW9uOjpu b3RpZnkoUU9iamVjdCosIFFFdmVudCopICgpCiAgIGZyb20gL3Vzci9saWIvbGliUXQ1V2lkZ2V0 cy5zby41CiMxOCAweDAwMDA3Zjc1ZTk3YzFhOWIgaW4gUUNvcmVBcHBsaWNhdGlvbjo6bm90aWZ5 SW50ZXJuYWwoUU9iamVjdCosIFFFdmVudCopCiAgICAoKSBmcm9tIC91c3IvbGliL2xpYlF0NUNv cmUuc28uNQojMTkgMHgwMDAwN2Y3NWU5N2MzYWRiIGluIFFDb3JlQXBwbGljYXRpb25Qcml2YXRl OjpzZW5kUG9zdGVkRXZlbnRzKFFPYmplY3QqLCBpbnQsIFFUaHJlYWREYXRhKikgKCkgZnJvbSAv dXNyL2xpYi9saWJRdDVDb3JlLnNvLjUKIzIwIDB4MDAwMDdmNzVlOTgxNjVkMiBpbiBRRXZlbnRE aXNwYXRjaGVyVU5JWDo6cHJvY2Vzc0V2ZW50cyhRRmxhZ3M8UUV2ZW50TG9vcDo6UHJvY2Vzc0V2 ZW50c0ZsYWc+KSAoKSBmcm9tIC91c3IvbGliL2xpYlF0NUNvcmUuc28uNQojMjEgMHgwMDAwN2Y3 NWQzYThjNGFkIGluID8/ICgpIGZyb20gL3Vzci9saWIvcXQvcGx1Z2lucy9wbGF0Zm9ybXMvbGli cXhjYi5zbwojMjIgMHgwMDAwN2Y3NWU5N2JmNTMyIGluIFFFdmVudExvb3A6OmV4ZWMoUUZsYWdz PFFFdmVudExvb3A6OlByb2Nlc3NFdmVudHNGbGFnPikgKCkgZnJvbSAvdXNyL2xpYi9saWJRdDVD b3JlLnNvLjUKIzIzIDB4MDAwMDdmNzVlOTdjNmYwYyBpbiBRQ29yZUFwcGxpY2F0aW9uOjpleGVj KCkgKCkKICAgZnJvbSAvdXNyL2xpYi9saWJRdDVDb3JlLnNvLjUKIzI0IDB4MDAwMDdmNzVlYjI2 N2EwYiBpbiBrZGVtYWluIChhcmdjPTEsIGFyZ3Y9MHg3ZmZmZWI2ODYyZDgpCiAgICBhdCAvaG9t ZS9zcGI0MS9idWlsZC9rd2luL3RydW5rL3NyYy9rd2luLTUuMi4wLjEvbWFpbl94MTEuY3BwOjI5 NAojMjUgMHgwMDAwN2Y3NWVhZWUwMDQwIGluIF9fbGliY19zdGFydF9tYWluICgpIGZyb20gL3Vz ci9saWIvbGliYy5zby42CiMyNiAweDAwMDAwMDAwMDA0MDA3ZGUgaW4gX3N0YXJ0ICgpCnF1aXQK QSBkZWJ1Z2dpbmcgc2Vzc2lvbiBpcyBhY3RpdmUuCgoJSW5mZXJpb3IgMSBbcHJvY2VzcyAxMzIw XSB3aWxsIGJlIGRldGFjaGVkLgoKUXVpdCBhbnl3YXk/ICh5IG9yIG4pIERldGFjaGluZyBmcm9t IHByb2dyYW06IC91c3IvYmluL2t3aW5feDExLCBwcm9jZXNzIDEzMjAK 90828 2015-01-31 03:16:05 +0000 2015-01-31 03:16:05 +0000 Patch to 'fix' hang on deletion by not deleting object glDeleteSync.patch text/plain 376 bladud LS0tIHNjZW5lX29wZW5nbC5jcHAJMjAxNS0wMS0zMCAyMjoxMjo0NS4xNjc1NTMwODIgLTA1MDAK KysrIHNjZW5lX29wZW5nbF9tb2QuY3BwCTIwMTUtMDEtMzAgMjI6MTI6NDAuNzAxMDUzNzYzIC0w NTAwCkBAIC0xMjEsNyArMTIxLDcgQEAKIFN5bmNPYmplY3Q6On5TeW5jT2JqZWN0KCkKIHsKICAg ICB4Y2Jfc3luY19kZXN0cm95X2ZlbmNlKGNvbm5lY3Rpb24oKSwgbV9mZW5jZSk7Ci0gICAgZ2xE ZWxldGVTeW5jKG1fc3luYyk7CisgICAgLy9nbERlbGV0ZVN5bmMobV9zeW5jKTsKIAogICAgIGlm IChtX3N0YXRlID09IFJlc2V0dGluZykKICAgICAgICAgeGNiX2Rpc2NhcmRfcmVwbHkoY29ubmVj dGlvbigpLCBtX3Jlc2V0X2Nvb2tpZS5zZXF1ZW5jZSk7Cg== 90873 2015-02-02 14:45:11 +0000 2015-02-02 14:45:11 +0000 stop stap control before deleting sync objects __bug343551.diff text/plain 5444 thomas.luebking ZGlmZiAtLWdpdCBhL2VnbG9ueGJhY2tlbmQuY3BwIGIvZWdsb254YmFja2VuZC5jcHAKaW5kZXgg ZDU0NjM1Yi4uMDk5MTU1YiAxMDA2NDQKLS0tIGEvZWdsb254YmFja2VuZC5jcHAKKysrIGIvZWds b254YmFja2VuZC5jcHAKQEAgLTEyOSw5ICsxMjksOCBAQCB2b2lkIEVnbE9uWEJhY2tlbmQ6Omlu aXQoKQogICAgICAgICAgICAgRUdMaW50IHZhbDsKICAgICAgICAgICAgIGVnbEdldENvbmZpZ0F0 dHJpYihkcHksIGNvbmZpZywgRUdMX01BWF9TV0FQX0lOVEVSVkFMLCAmdmFsKTsKICAgICAgICAg ICAgIGlmICh2YWwgPj0gMSkgewotICAgICAgICAgICAgICAgIGlmIChlZ2xTd2FwSW50ZXJ2YWwo ZHB5LCAxKSkgeworICAgICAgICAgICAgICAgIGlmIChzZXRTd2FwSW50ZXJ2YWwoMSkpIHsKICAg ICAgICAgICAgICAgICAgICAgcUNEZWJ1ZyhLV0lOX0NPUkUpIDw8ICJFbmFibGVkIHYtc3luYyI7 Ci0gICAgICAgICAgICAgICAgICAgIHNldFN5bmNzVG9WQmxhbmsodHJ1ZSk7CiAgICAgICAgICAg ICAgICAgICAgIGNvbnN0IFFCeXRlQXJyYXkgdHJpcGxlQnVmZmVyID0gcWdldGVudigiS1dJTl9U UklQTEVfQlVGRkVSIik7CiAgICAgICAgICAgICAgICAgICAgIGlmICghdHJpcGxlQnVmZmVyLmlz RW1wdHkoKSkgewogICAgICAgICAgICAgICAgICAgICAgICAgc2V0QmxvY2tzRm9yUmV0cmFjZShx c3RyY21wKHRyaXBsZUJ1ZmZlciwgIjAiKSA9PSAwKTsKQEAgLTE0NCw3ICsxNDMsNyBAQCB2b2lk IEVnbE9uWEJhY2tlbmQ6OmluaXQoKQogICAgICAgICAgICAgfQogICAgICAgICB9IGVsc2Ugewog ICAgICAgICAgICAgLy8gZGlzYWJsZSB2LXN5bmMKLSAgICAgICAgICAgIGVnbFN3YXBJbnRlcnZh bChkcHksIDApOworICAgICAgICAgICAgc2V0U3dhcEludGVydmFsKDApOwogICAgICAgICB9CiAg ICAgfSBlbHNlIHsKICAgICAgICAgLyogSW4gdGhlIEdMWCBiYWNrZW5kLCB3ZSBmYWxsIGJhY2sg dG8gdXNpbmcgZ2xDb3B5UGl4ZWxzIGlmIHdlIGhhdmUgbm8gZXh0ZW5zaW9uIHByb3ZpZGluZyBz dXBwb3J0IGZvciBwYXJ0aWFsIHNjcmVlbiB1cGRhdGVzLgpAQCAtMzQwLDcgKzMzOSw3IEBAIHZv aWQgRWdsT25YQmFja2VuZDo6cHJlc2VudCgpCiAgICAgICAgICAgICAgICAgICAgIC8vIFRPRE8g dGhpcyBpcyBhIHdvcmthcm91bmQsIHdlIHNob3VsZCBnZXQgX19HTF9ZSUVMRCBzZXQgYmVmb3Jl IGxpYkdMIGNoZWNrcyBpdAogICAgICAgICAgICAgICAgICAgICBpZiAocXN0cmNtcChxZ2V0ZW52 KCJfX0dMX1lJRUxEIiksICJVU0xFRVAiKSkgewogICAgICAgICAgICAgICAgICAgICAgICAgb3B0 aW9ucy0+c2V0R2xQcmVmZXJCdWZmZXJTd2FwKDApOwotICAgICAgICAgICAgICAgICAgICAgICAg ZWdsU3dhcEludGVydmFsKGRweSwgMCk7CisgICAgICAgICAgICAgICAgICAgICAgICBzZXRTd2Fw SW50ZXJ2YWwoMCk7CiAgICAgICAgICAgICAgICAgICAgICAgICBxQ1dhcm5pbmcoS1dJTl9DT1JF KSA8PCAiXG5JdCBzZWVtcyB5b3UgYXJlIHVzaW5nIHRoZSBudmlkaWEgZHJpdmVyIHdpdGhvdXQg dHJpcGxlIGJ1ZmZlcmluZ1xuIgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIllvdSBtdXN0IGV4cG9ydCBfX0dMX1lJRUxEPVwiVVNMRUVQXCIgdG8gcHJldmVudCBs YXJnZSBDUFUgb3ZlcmhlYWQgb24gc3luY2VkIHN3YXBzXG4iCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAiUHJlZmVyYWJseSwgZW5hYmxlIHRoZSBUcmlwbGVCdWZm ZXIgT3B0aW9uIGluIHRoZSB4b3JnLmNvbmYgRGV2aWNlXG4iCkBAIC00NzEsNiArNDcwLDE1IEBA IE92ZXJsYXlXaW5kb3cqIEVnbE9uWEJhY2tlbmQ6Om92ZXJsYXlXaW5kb3coKQogICAgIHJldHVy biBtX292ZXJsYXlXaW5kb3c7CiB9CiAKK2Jvb2wgRWdsT25YQmFja2VuZDo6c2V0U3dhcEludGVy dmFsKGludCBpbnRlcnZhbCkKK3sKKyAgICBpZiAoZWdsU3dhcEludGVydmFsKGRweSwgaW50ZXJ2 YWwpKSB7CisgICAgICAgIHNldFN5bmNzVG9WQmxhbmsoaW50ZXJ2YWwgPiAwKTsKKyAgICAgICAg cmV0dXJuIHRydWU7CisgICAgfQorICAgIHJldHVybiBmYWxzZTsKK30KKwogLyoqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgogICogRWdsVGV4dHVyZQogICoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KZGlmZiAtLWdp dCBhL2VnbG9ueGJhY2tlbmQuaCBiL2VnbG9ueGJhY2tlbmQuaAppbmRleCBkZTExZDIxLi45Njcx MjJiIDEwMDY0NAotLS0gYS9lZ2xvbnhiYWNrZW5kLmgKKysrIGIvZWdsb254YmFja2VuZC5oCkBA IC00MCw2ICs0MCw3IEBAIHB1YmxpYzoKICAgICB2aXJ0dWFsIHZvaWQgZG9uZUN1cnJlbnQoKSBv dmVycmlkZTsKICAgICB2aXJ0dWFsIE92ZXJsYXlXaW5kb3cqIG92ZXJsYXlXaW5kb3coKSBvdmVy cmlkZTsKICAgICB2aXJ0dWFsIGJvb2wgdXNlc092ZXJsYXlXaW5kb3coKSBjb25zdCBvdmVycmlk ZTsKKyAgICB2aXJ0dWFsIGJvb2wgc2V0U3dhcEludGVydmFsKGludCBpbnRlcnZhbCkgb3ZlcnJp ZGU7CiAKIHByb3RlY3RlZDoKICAgICB2aXJ0dWFsIHZvaWQgcHJlc2VudCgpOwpkaWZmIC0tZ2l0 IGEvZ2x4YmFja2VuZC5jcHAgYi9nbHhiYWNrZW5kLmNwcAppbmRleCBjOTdmYmVlLi45MDc3N2Ux IDEwMDY0NAotLS0gYS9nbHhiYWNrZW5kLmNwcAorKysgYi9nbHhiYWNrZW5kLmNwcApAQCAtMjIx LDcgKzIyMSw2IEBAIHZvaWQgR2x4QmFja2VuZDo6aW5pdCgpCiAgICAgaWYgKHdhbnRTeW5jICYm IGdsWElzRGlyZWN0KGRpc3BsYXkoKSwgY3R4KSkgewogICAgICAgICBpZiAoaGF2ZVN3YXBJbnRl cnZhbCkgeyAvLyBnbFhTd2FwSW50ZXJ2YWwgaXMgcHJlZmVycmVkIGJlaW5nIG1vcmUgcmVsaWFi bGUKICAgICAgICAgICAgIHNldFN3YXBJbnRlcnZhbCgxKTsKLSAgICAgICAgICAgIHNldFN5bmNz VG9WQmxhbmsodHJ1ZSk7CiAgICAgICAgICAgICBjb25zdCBRQnl0ZUFycmF5IHRyaXBsZUJ1ZmZl ciA9IHFnZXRlbnYoIktXSU5fVFJJUExFX0JVRkZFUiIpOwogICAgICAgICAgICAgaWYgKCF0cmlw bGVCdWZmZXIuaXNFbXB0eSgpKSB7CiAgICAgICAgICAgICAgICAgc2V0QmxvY2tzRm9yUmV0cmFj ZShxc3RyY21wKHRyaXBsZUJ1ZmZlciwgIjAiKSA9PSAwKTsKQEAgLTU5Miw3ICs1OTEsNyBAQCBG QkNvbmZpZ0luZm8gKkdseEJhY2tlbmQ6OmluZm9Gb3JWaXN1YWwoeGNiX3Zpc3VhbGlkX3Qgdmlz dWFsKQogICAgIHJldHVybiBpbmZvOwogfQogCi12b2lkIEdseEJhY2tlbmQ6OnNldFN3YXBJbnRl cnZhbChpbnQgaW50ZXJ2YWwpCitib29sIEdseEJhY2tlbmQ6OnNldFN3YXBJbnRlcnZhbChpbnQg aW50ZXJ2YWwpCiB7CiAgICAgaWYgKG1faGF2ZUVYVFN3YXBDb250cm9sKQogICAgICAgICBnbFhT d2FwSW50ZXJ2YWxFWFQoZGlzcGxheSgpLCBnbHhXaW5kb3csIGludGVydmFsKTsKQEAgLTYwMCw2 ICs1OTksMTAgQEAgdm9pZCBHbHhCYWNrZW5kOjpzZXRTd2FwSW50ZXJ2YWwoaW50IGludGVydmFs KQogICAgICAgICBnbFhTd2FwSW50ZXJ2YWxNRVNBKGludGVydmFsKTsKICAgICBlbHNlIGlmICht X2hhdmVTR0lTd2FwQ29udHJvbCkKICAgICAgICAgZ2xYU3dhcEludGVydmFsU0dJKGludGVydmFs KTsKKyAgICBlbHNlCisgICAgICAgIHJldHVybiBmYWxzZTsKKyAgICBzZXRTeW5jc1RvVkJsYW5r KGludGVydmFsID4gMCk7CisgICAgcmV0dXJuIHRydWU7CiB9CiAKIHZvaWQgR2x4QmFja2VuZDo6 d2FpdFN5bmMoKQpkaWZmIC0tZ2l0IGEvZ2x4YmFja2VuZC5oIGIvZ2x4YmFja2VuZC5oCmluZGV4 IDI2MDNlZDcuLjc1YWU5NTggMTAwNjQ0Ci0tLSBhL2dseGJhY2tlbmQuaAorKysgYi9nbHhiYWNr ZW5kLmgKQEAgLTcwLDYgKzcwLDcgQEAgcHVibGljOgogICAgIHZpcnR1YWwgdm9pZCBkb25lQ3Vy cmVudCgpIG92ZXJyaWRlOwogICAgIHZpcnR1YWwgT3ZlcmxheVdpbmRvdyogb3ZlcmxheVdpbmRv dygpIG92ZXJyaWRlOwogICAgIHZpcnR1YWwgYm9vbCB1c2VzT3ZlcmxheVdpbmRvdygpIGNvbnN0 IG92ZXJyaWRlOworICAgIHZpcnR1YWwgYm9vbCBzZXRTd2FwSW50ZXJ2YWwoaW50IGludGVydmFs KSBvdmVycmlkZTsKIAogcHJvdGVjdGVkOgogICAgIHZpcnR1YWwgdm9pZCBwcmVzZW50KCk7CkBA IC04MSw3ICs4Miw2IEBAIHByaXZhdGU6CiAgICAgYm9vbCBpbml0UmVuZGVyaW5nQ29udGV4dCgp OwogICAgIGJvb2wgaW5pdEZiQ29uZmlnKCk7CiAgICAgdm9pZCBpbml0VmlzdWFsRGVwdGhIYXNo VGFibGUoKTsKLSAgICB2b2lkIHNldFN3YXBJbnRlcnZhbChpbnQgaW50ZXJ2YWwpOwogCiAgICAg aW50IHZpc3VhbERlcHRoKHhjYl92aXN1YWxpZF90IHZpc3VhbCkgY29uc3Q7CiAgICAgRkJDb25m aWdJbmZvICppbmZvRm9yVmlzdWFsKHhjYl92aXN1YWxpZF90IHZpc3VhbCk7CmRpZmYgLS1naXQg YS9zY2VuZV9vcGVuZ2wuY3BwIGIvc2NlbmVfb3BlbmdsLmNwcAppbmRleCBjNmU5ZDUwLi40ZDlj MDNkIDEwMDY0NAotLS0gYS9zY2VuZV9vcGVuZ2wuY3BwCisrKyBiL3NjZW5lX29wZW5nbC5jcHAK QEAgLTQxMiw2ICs0MTIsNyBAQCBTY2VuZU9wZW5HTDo6flNjZW5lT3BlbkdMKCkKICAgICAvLyBk byBjbGVhbnVwIGFmdGVyIGluaXRCdWZmZXIoKQogICAgIFNjZW5lT3BlbkdMOjpFZmZlY3RGcmFt ZTo6Y2xlYW51cCgpOwogICAgIGlmIChpbml0X29rKSB7CisgICAgICAgIG1fYmFja2VuZC0+c2V0 U3dhcEludGVydmFsKDApOyAvLyBwcmV2ZW50IH5TeW5jT2JqZWN0IGZyb20gYmxvY2tpbmcgc3dh cCBjYWxsIChldmVuIGluIHRyaXBsZSBidWZmZXJpbmcpLCAjMzQzNTUxCiAgICAgICAgIGRlbGV0 ZSBtX3N5bmNNYW5hZ2VyOwogCiAgICAgICAgIC8vIGJhY2tlbmQgbWlnaHQgYmUgc3RpbGwgbmVl ZGVkIGZvciBhIGRpZmZlcmVudCBzY2VuZQpkaWZmIC0tZ2l0IGEvc2NlbmVfb3BlbmdsLmggYi9z Y2VuZV9vcGVuZ2wuaAppbmRleCA0Y2FmMmVmLi44NDEyMzNhIDEwMDY0NAotLS0gYS9zY2VuZV9v cGVuZ2wuaAorKysgYi9zY2VuZV9vcGVuZ2wuaApAQCAtNDM1LDYgKzQzNSwxMiBAQCBwdWJsaWM6 CiAgICAgICAgIHJldHVybiBtX2ZhaWxlZDsKICAgICB9CiAgICAgLyoqCisgICAgICogQGJyaWVm IEFic3RyYWN0cyB0aGUgZGlmZmVyZW50ICpzd2FwSW50ZXJ2YWwqIGNhbGxzCisgICAgICogcmV0 dXJucyB3aGV0aGVyIHRoZSBjYWxsIHN1Y2NlZWRlZAorICAgICAqIGltcGxpY2l0bHkgaW1wYWN0 cyBzeW5jc1RvVkJsYW5rKCkKKyAgICAgKiovCisgICAgdmlydHVhbCBib29sIHNldFN3YXBJbnRl cnZhbChpbnQgaSkgPSAwOworICAgIC8qKgogICAgICAqIEBicmllZiBXaGV0aGVyIHRoZSBCYWNr ZW5kIHByb3ZpZGVzIFZTeW5jLgogICAgICAqCiAgICAgICogQ3VycmVudGx5IG9ubHkgdGhlIEdM WCBiYWNrZW5kIGNhbiBwcm92aWRlIFZTeW5jLgo= 91085 2015-02-15 04:45:00 +0000 2015-02-28 22:46:38 +0000 Another patch to fix the hang by manually triggering the xcb fence. fix_nvidia.patch text/plain 951 bladud LS0tIHNjZW5lX29wZW5nbC5jcHAub3JpZwkyMDE1LTAyLTE0IDIzOjM5OjMyLjQ3OTk0MjA3NiAt MDUwMAorKysgc2NlbmVfb3BlbmdsLmNwcAkyMDE1LTAyLTE0IDIzOjMyOjM2LjU4MDQ2OTUwNiAt MDUwMApAQCAtMTIwLDYgKzEyMCwxOCBAQAogCiBTeW5jT2JqZWN0Ojp+U3luY09iamVjdCgpCiB7 CisgICAgLy8gVGhpcyBpcyBhIGZpeCBmb3IgYW4gbnZpZGlhIGRyaXZlciBidWcgaW4gdjMwNC4K KyAgICAvLyBJZiBnbERlbGV0ZVN5bmMgaXMgY2FsbGVkIGJlZm9yZSB0aGUgeGNiIGZlbmNlIGlz IHRyaWdnZXJlZC4KKyAgICAvLyB0aGUgbnZpZGlhIGRyaXZlciBkZWFkbG9ja3MgaW4gZ2xEZWxl dGVTeW5jIGJ1c3ktd2FpdGluZyBvbiBzb21ldGhpbmcsCisgICAgLy8gcG9zc2libHkgYW4gaW50 ZXJuYWwgcmVzb3VyY2UgY29ubmVjdGVkIHRvIHRoZSB4Y2IgZmVuY2UuCisgICAgLy8gVG8gYXZv aWQgdGhpcywgbWFudWFsbHkgdHJpZ2dlciB0aGUgZmVuY2UgaGVyZS4KKyAgICBpZiAobV9zdGF0 ZSA9PSBSZXNldHRpbmcgfHwgbV9zdGF0ZSA9PSBSZWFkeSl7CisgICAgICAgIHRyaWdnZXIoKTsK KyAgICAgICAgLy8gVGhlIGZsdXNoIGlzIG5lY2Vzc2FyeSEgVGhlIEdMIGRyaXZlciBuZWVkcyB0 byBrbm93IHRoYXQgdGhlIGZlbmNlIGlzIHRyaWdnZXJlZC4KKyAgICAgICAgLy8gRGFuZ2VyOiB3 ZSBoYW5nIGFsc28gaWYgZ2xXYWl0U3luYyBpcyBjYWxsZWQgaGVyZS4KKyAgICAgICAgLy8gSWYg d2FpdCgpIGlzIGNhbGxlZCBhZnRlciB0cmlnZ2VyKCkgZmFzdCBlbm91Z2ggZm9yIHNvbWUgb3Ro ZXIgcmVhc29uIGNvdWxkIGl0IHN0aWxsIGhhbmc/CisgICAgICAgIHhjYl9mbHVzaChjb25uZWN0 aW9uKCkpOworICAgIH0KICAgICB4Y2Jfc3luY19kZXN0cm95X2ZlbmNlKGNvbm5lY3Rpb24oKSwg bV9mZW5jZSk7CiAgICAgZ2xEZWxldGVTeW5jKG1fc3luYyk7CiAK 91353 2015-02-28 22:46:38 +0000 2015-02-28 22:46:38 +0000 Updated patch to fix hang by triggering fence fix_nvidia.patch text/plain 761 bladud LS0tIHNjZW5lX29wZW5nbC5jcHAub3JpZwkyMDE1LTAyLTE0IDIzOjM5OjMyLjQ3OTk0MjA3NiAt MDUwMAorKysgc2NlbmVfb3BlbmdsLmNwcAkyMDE1LTAyLTI4IDE3OjQ0OjM5LjI0NDIwMzI0MCAt MDUwMApAQCAtMTIwLDYgKzEyMCwxNyBAQAogCiBTeW5jT2JqZWN0Ojp+U3luY09iamVjdCgpCiB7 CisgICAgLy8gSWYgZ2xEZWxldGVTeW5jIGlzIGNhbGxlZCBiZWZvcmUgdGhlIHhjYiBmZW5jZSBp cyBzaWduYWxsZWQKKyAgICAvLyB0aGUgbnZpZGlhIGRyaXZlciAodGhlIG9ubHkgb25lIHRvIGlt cGxlbWVudCBHTF9TWU5DX1gxMV9GRU5DRV9FWFQpCisgICAgLy8gZGVhZGxvY2tzIHdhaXRpbmcg Zm9yIHRoZSBmZW5jZSB0byBiZSBzaWduYWxsZWQuCisgICAgLy8gVG8gYXZvaWQgdGhpcywgbWFr ZSBzdXJlIHRoZSBmZW5jZSBpcyBzaWduYWxsZWQgYmVmb3JlIAorICAgIC8vIGRlbGV0aW5nIHRo ZSBzeW5jLgorICAgIGlmIChtX3N0YXRlID09IFJlc2V0dGluZyB8fCBtX3N0YXRlID09IFJlYWR5 KXsKKyAgICAgICAgdHJpZ2dlcigpOworICAgICAgICAvLyBUaGUgZmx1c2ggaXMgbmVjZXNzYXJ5 ISAKKyAgICAgICAgLy8gVGhlIHRyaWdnZXIgY29tbWFuZCBuZWVkcyB0byBiZSBzZW50IHRvIHRo ZSBYIHNlcnZlciAKKyAgICAgICAgeGNiX2ZsdXNoKGNvbm5lY3Rpb24oKSk7CisgICAgfQogICAg IHhjYl9zeW5jX2Rlc3Ryb3lfZmVuY2UoY29ubmVjdGlvbigpLCBtX2ZlbmNlKTsKICAgICBnbERl bGV0ZVN5bmMobV9zeW5jKTsKIAo=