OS: Opensuse factory x86_64 KDE Framework 5.1 Plasma shell 5.0.1 After switching to plasma 5 desktop in opensuse factory, time to time desktop freezes. I can move mouse but nothing works. I can't click anywhere. I then restart session with CTRL+ALT+F7. I thought it is X.ORG or Kernel problem as it was freezing. But I didn't notice any such logs in /var/log/messages or X.org logs. Then once I hit ALT+TAB and desktop started behaving normal. Now I can always reproduce it. It keep freezing every few hours and I can resume it with ALT+TAB. So it seems something wrong with painting the desktop shell. I usually use google chrome, dolphin, libreoffice, konsole and skype apps. Reproducible: Always Steps to Reproduce: 1. Use plasma desktop 5 for extended period of time. Actual Results: Desktop freezes Expected Results: Desktop should operate normally.
Could also be related to kwin. I remember that I got freezes when just running kwin/5 with Plasma 4.
Does this happened after disconnecting a monitor? We need some more info before we can do anything on this. Maybe you can leave top/ksysguard open? Does running DISPLAY=:0 kwin_x11 --replace from a real terminal fix it?
I don't use secondary monitor. It randomly happens time to time on my laptop. I didn't try that command because just hitting ALT+TAB fixes it. So seems like screen paint issue.
I just experienced again and checked top in other terminal, the output was normal.
If alt+tab fixes it it sounds like kwin is at fault. Please attach the output of: $ qdbus org.kde.kwin /KWin org.kde.KWin.supportInformation
Created attachment 88799 [details] Kwin log
I highly suggest to switch to a different window decoration (Aurorae will not give you a good experience with your hardware).
Created attachment 88800 [details] window decoration setting Not sure why it shows aurorae, I'm using Breeze. I don't even have aurorae decoration. It just shows 3 options, breeze, oxygen and plastik.
Breeze uses Aurorae
a) define "freeze" - does any output update? (eg. a clock)? If not, does suspending the compositor (Shift+Alt+F12) turn the screen responsive again? b) ctrl+alt+f7 should rather not restart the session. Is tihs really the case for you, or did you mean to restart the session from VT1 an then switch back to VT7? c) Only interesting if output is still updated (ie. not compositing related) -> Install xdotool. When this happens the next time, on VT1 (or via ssh) run: DISPLAY=:0 xdotool key "XF86LogGrabInfo" then check /var/log/Xorg.0.log for device grabs: sed -n 'H; /Printing all currently active device grabs/h; ${g;p;}' /var/log/Xorg.0.log (hint: you may want to stuff those commands into a bash script for easy calling. In case, put a "sleep 1" between the two commands) Dev note: could be related to bug #337853?
I checked all details. When it just happened. I had chrome and skype open. a) It didn't update clock. Hitting ALT+SHIFT+F12 made taskbar responsive but desktop was still not responding. So I could launch new program. Open calendar, access systemtray but nothing will reflect on rest of the screen though. Eventually it crashed kwin and I could see applications without title bar. b) CTRL+ALT+F7 had no effect. c) No device grabs reported. I had to restart kwin. It didn't trigger dr konqui after that though.
(In reply to Ruchir Brahmbhatt from comment #11) > a) It didn't update clock. Hitting ALT+SHIFT+F12 made taskbar responsive but > desktop was still not responding. So I could launch new program. Open > calendar, access systemtray but nothing will reflect on rest of the screen > though. Eventually it crashed kwin and I could see applications without > title bar. This makes no sense (ie. seems self-contradicting) For clarification: after suspending the compositor, (some) *present* windows turned responsive, but you could not get *new* windows on screen? Could you pass the focus around among existing windows (eg. make firefox the active window and then konsole etc.)?
After suspending compositor, taskbar turned responsive but no windows were responsive. Last window is shown on screen. Nothing happens when I select other windows I still see google chrome only. I tried to start dolphin from launcher which didn't start though and I think kwin crashed after that. Was very weird and confusing behavior.
See bug #313830 Do you eventually use XIM (or "fcitx")? Can you gdb into the frozen kwin from VT1?
I could gdb into frozen kwin and got below bt. I don't understand the XIM part. (gdb) bt #0 0x00007ff9a7668a63 in select () from /lib64/libc.so.6 #1 0x00007ff9a57b6cb9 in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timespec const*) () from /usr/lib64/libQt5Core.so.5 #2 0x00007ff9a57b862f in QEventDispatcherUNIXPrivate::doSelect(QFlags<QEventLoop::ProcessEventsFlag>, timespec*) () from /usr/lib64/libQt5Core.so.5 #3 0x00007ff9a57b8a8b in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5 #4 0x00007ff991bed8ed in ?? () from /usr/lib64/qt5/plugins/platforms/libqxcb.so #5 0x00007ff9a5761a6b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5 #6 0x00007ff9a57690c6 in QCoreApplication::exec() () from /usr/lib64/libQt5Core.so.5 #7 0x00007ff9a7936beb in kdemain (argc=1, argv=0x7fff83c24d98) at /usr/src/debug/kwin-5.0.95~git20140911/main_x11.cpp:294 #8 0x00007ff9a75abb05 in __libc_start_main () from /lib64/libc.so.6 #9 0x00000000004008ce in _start () at ../sysdeps/x86_64/start.S:122
That thread seems dormant, you want to inspect the existing threads and switch between them, see eg. https://sourceware.org/gdb/current/onlinedocs/gdb/Threads.html XIM is for input of non-latin text - it's often used in asia, but i don't know about india. http://en.wikipedia.org/wiki/Fcitx It's also known for the potential to stall xcb event processing: https://bugs.kde.org/show_bug.cgi?id=313830
I use english language only so probably XIM is not in use. Please find bt of all threads below. (gdb) info threads Id Target Id Frame 5 Thread 0x7fe6a346c700 (LWP 1505) "QXcbEventReader" 0x00007fe6b09f805f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 4 Thread 0x7fe6a0985700 (LWP 1508) "QProcessManager" 0x00007fe6b9c0aa63 in select () from /lib64/libc.so.6 3 Thread 0x7fe693bb1700 (LWP 1532) "QQmlThread" 0x00007fe6b9c0aa63 in select () from /lib64/libc.so.6 2 Thread 0x7fe68bfff700 (LWP 1548) "kwin_x11" 0x00007fe6b09f805f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 * 1 Thread 0x7fe6ba26d800 (LWP 1502) "kwin_x11" 0x00007fe6b9c0aa63 in select () from /lib64/libc.so.6 (gdb) bt #0 0x00007fe6b9c0aa63 in select () from /lib64/libc.so.6 #1 0x00007fe6b7d58cb9 in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timespec const*) () from /usr/lib64/libQt5Core.so.5 #2 0x00007fe6b7d5a62f in QEventDispatcherUNIXPrivate::doSelect(QFlags<QEventLoop::ProcessEventsFlag>, timespec*) () from /usr/lib64/libQt5Core.so.5 #3 0x00007fe6b7d5aa8b in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5 #4 0x00007fe6a418f8ed in ?? () from /usr/lib64/qt5/plugins/platforms/libqxcb.so #5 0x00007fe6b7d03a6b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5 #6 0x00007fe6b7d0b0c6 in QCoreApplication::exec() () from /usr/lib64/libQt5Core.so.5 #7 0x00007fe6b9ed8beb in kdemain (argc=1, argv=0x7fffbc4e4588) at /usr/src/debug/kwin-5.0.95~git20140911/main_x11.cpp:294 #8 0x00007fe6b9b4db05 in __libc_start_main () from /lib64/libc.so.6 #9 0x00000000004008ce in _start () at ../sysdeps/x86_64/start.S:122 (gdb) thread 2 [Switching to thread 2 (Thread 0x7fe68bfff700 (LWP 1548))] #0 0x00007fe6b09f805f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 (gdb) bt #0 0x00007fe6b09f805f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fe6b60d8fbb in ?? () from /usr/lib64/libQt5Script.so.5 #2 0x00007fe6b60d8fe9 in ?? () from /usr/lib64/libQt5Script.so.5 #3 0x00007fe6b09f40a4 in start_thread () from /lib64/libpthread.so.0 #4 0x00007fe6b9c117fd in clone () from /lib64/libc.so.6 (gdb) thread 3 [Switching to thread 3 (Thread 0x7fe693bb1700 (LWP 1532))] #0 0x00007fe6b9c0aa63 in select () from /lib64/libc.so.6 (gdb) bt #0 0x00007fe6b9c0aa63 in select () from /lib64/libc.so.6 #1 0x00007fe6b7d58cb9 in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timespec const*) () from /usr/lib64/libQt5Core.so.5 #2 0x00007fe6b7d5a62f in QEventDispatcherUNIXPrivate::doSelect(QFlags<QEventLoop::ProcessEventsFlag>, timespec*) () from /usr/lib64/libQt5Core.so.5 #3 0x00007fe6b7d5aa8b in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5 #4 0x00007fe6b7d03a6b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5 #5 0x00007fe6b7b22eca in QThread::exec() () from /usr/lib64/libQt5Core.so.5 #6 0x00007fe6b7b27b3f in ?? () from /usr/lib64/libQt5Core.so.5 #7 0x00007fe6b09f40a4 in start_thread () from /lib64/libpthread.so.0 #8 0x00007fe6b9c117fd in clone () from /lib64/libc.so.6 (gdb) (gdb) thread 4 [Switching to thread 4 (Thread 0x7fe6a0985700 (LWP 1508))] #0 0x00007fe6b9c0aa63 in select () from /lib64/libc.so.6 (gdb) bt #0 0x00007fe6b9c0aa63 in select () from /lib64/libc.so.6 #1 0x00007fe6b7c9c9ef in ?? () from /usr/lib64/libQt5Core.so.5 #2 0x00007fe6b7b27b3f in ?? () from /usr/lib64/libQt5Core.so.5 #3 0x00007fe6b09f40a4 in start_thread () from /lib64/libpthread.so.0 #4 0x00007fe6b9c117fd in clone () from /lib64/libc.so.6 (gdb) thread 5 [Switching to thread 5 (Thread 0x7fe6a346c700 (LWP 1505))] #0 0x00007fe6b09f805f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 (gdb) bt #0 0x00007fe6b09f805f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fe6b7870569 in ?? () from /usr/lib64/libxcb.so.1 #2 0x00007fe6b7871def in xcb_wait_for_event () from /usr/lib64/libxcb.so.1 #3 0x00007fe6a41400c9 in ?? () from /usr/lib64/qt5/plugins/platforms/libqxcb.so #4 0x00007fe6b7b27b3f in ?? () from /usr/lib64/libQt5Core.so.5 #5 0x00007fe6b09f40a4 in start_thread () from /lib64/libpthread.so.0 #6 0x00007fe6b9c117fd in clone () from /lib64/libc.so.6 (gdb) info threads Id Target Id Frame * 5 Thread 0x7fe6a346c700 (LWP 1505) "QXcbEventReader" 0x00007fe6b09f805f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 4 Thread 0x7fe6a0985700 (LWP 1508) "QProcessManager" 0x00007fe6b9c0aa63 in select () from /lib64/libc.so.6 3 Thread 0x7fe693bb1700 (LWP 1532) "QQmlThread" 0x00007fe6b9c0aa63 in select () from /lib64/libc.so.6 2 Thread 0x7fe68bfff700 (LWP 1548) "kwin_x11" 0x00007fe6b09f805f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 1 Thread 0x7fe6ba26d800 (LWP 1502) "kwin_x11" 0x00007fe6b9c0aa63 in select () from /lib64/libc.so.6 (gdb)
> #3 0x00007fe6a41400c9 in ?? () from /usr/lib64/qt5/plugins/platforms/libqxcb.so > #4 0x00007fe6b7b27b3f in ?? () from /usr/lib64/libQt5Core.so.5 Unfortunately there're no debug symbols, yet > #2 0x00007fe6b7871def in xcb_wait_for_event () from /usr/lib64/libxcb.so.1 it seems to hang in xcb_wait_for_event (like the xim bug, which however may just be a xim *induced* bug in Qt) You're now running the oxygen deco, I assume? Let's see whether it happens with this as well ;-)
> > #2 0x00007fe6b7871def in xcb_wait_for_event () from > > /usr/lib64/libxcb.so.1 > > it seems to hang in xcb_wait_for_event (like the xim bug, which however may > just be a xim *induced* bug in Qt) well that's what the xcb event reading thread is supposed to do. Hang there and wait for the next event.
yes, but from the description, events are not received/processed and no other thread seems locked at some point... i didn't mean "this is the cause", but "this seems the relevat symptom" (at least i can't see any other) we might have "lost" the xcb connection or just event selection. no ida on the cause, though.
Just an update, keeping compositor off doesn't freeze desktop anymore. I could use full day without single freeze.
Did you hit it with oxygen deco + compositing?
Yes due to bug #339235, I used oxygen instead of breeze and yet it was freezing. After disabling compositing, it no longer freezes.
A possible cause is kwin calling SwapBuffers() from prepareRenderingFrame(). With Qt 5 kwin must return to the event loop after calling SwapBuffers(), or Mesa won't see the buffer invalidate event and rendering will be lost.
Using Plasma 5.1beta on openSUSE, I also have irregular occurring freezes like described here.
Does your screen look anything like this http://i.imgur.com/wWP91KJ.jpg when it gets frozen?
your screen looks like another bug, i see regularly. is it combined with flickering?
There maybe flicker I am not 100% sure. Mouse works. From what I can tell everything is running in back ground. I can run commands through KRunner. I think some application gets frozen and blackened in front which makes everything behind it unusable. My rough guess is Breeze Window decoration is behind it. I have reinstalled Plasma 5 from scratch. I am slowly changing defaults theme defaults one at a time. As far as graphics is considered Breeze window decoration is the only thing that I don't have right now.
short update: using plasma 5.1 final and KF 5.3 the bug is still occuring. When I deactivate compositing it is gone.
Rolling back to an old version at: https://build.opensuse.org/package/show?project=home%3Asumski%3Atest&package=xf86-video-intel seems to have fixed the freezing problem. Mesa updated to 10.3.1 and intel .916 didn't fix the problem. It is version 2.99.911 versus Factory's 916, and the biggest apparent difference is that there is no DRI3 in the old one. So it seems there is a problem with new intel drivers with Gen4.5 with DRI3.
I also had the freezes with intel, but I did only use openSUSE 13.1 versions, which still has Mesa 9.2.3 and intel 2.99.906. Chipset is 945GM (8086:27a2 / 8086:27a6).
Check: grep -i glamor /var/log/Xorg.0.log
Sorry, for interrupting, but here is some more information on this bug. As I have noticed, this freeze happens more frequently when picture on the screen is changing fast & abundantly (i.e. watching a full-screen|part-screen video, scrolling a page in browser, using visualizer in Amarok). And when there's almost nothing happening on the screen -- it's almost imposible to reproduce the bug. I am using: * Plasma 5.1 on top of Kubuntu 14.10 x86_64 * KDE Frameworks 5.3 * Intel HD 3000 video (Sandy Bridge) * xserver-xorg-video-intel: 2:2.99.914-1~exp1ubuntu4.1 * mesa: 10.3.0-0ubuntu3 $ grep -i glamor /var/log/Xorg.0.log [ 22.827] (WW) "glamoregl" will not be loaded unless you've specified it to be loaded elsewhere.d elsewher KWin support information: http://paste.kde.org/p0bhhaqly Please do not hezitate to ask, if you will need some more information from me.
> Painting blocks for vertical retrace: no *Should* rule out comment #24 because KWin's then calling present() from endRenderingFrame(), invalidating lastDamage() Can someone try export KWIN_USE_BUFFER_AGE=0; kwin --replace &
> export KWIN_USE_BUFFER_AGE=0; kwin --replace & Works for me. No freeze was spotted when running kwin in this mode. Except one thing: after a screen shutdown (energy saving after 5 minutes of inactiveness) and waking up (e.g. move a mouse) it still shows some random picture (of my screen) from past. And I still have to press alt+tab to get back to normal picture (see the video). Automatic locking of the screen is turned off. Video is here: http://youtu.be/AjH1tA00yPg
See this thread on the "error on resume from STR". https://forum.kde.org/viewtopic.php?f=111&t=121590 (There's the hint to register the module to acpi and one on the second page which causes a video repost on resume from STR)
On Wednesday 12 November 2014 22:42:38 you wrote: > https://bugs.kde.org/show_bug.cgi?id=338999 > > --- Comment #35 from Kirill Bogdanenko <kirill.bogdanenko@gmail.com> --- > > > export KWIN_USE_BUFFER_AGE=0; kwin --replace & > > Works for me. No freeze was spotted when running kwin in this mode. with bug #340876 we have now two bug reports indicating problems with buffer age on Intel. Maybe temporary disable?
Bug #340876 is especially on Qt 5.4 and buffer age deactivating on reported to fix "still some breakage (partial rendering) when locking screen and getting back." which might just as well have been coincidental failure/success to repost the video memory.
*** Bug 341353 has been marked as a duplicate of this bug. ***
a bug 343260 may be related
I think I'm seeing this problem on my X220 laptop running Arch Linux. xf86-video-intel 2.99.917, mesa 10.4.3 and Plasma 5.2. The graphics is Intel HD 3000 i think. I'm using default Xorg configuration and kernel module parameters. What happens for me is that sometimes areas of the the shell / window manager is not updated to reflect changes. Sometimes I can force a single update to occur by switching virtual desktops, or switching to VT and back. E.g. I can click somewhere that would open say a context menu, nothing happens, then switch virtual desktop and back, and the menu is shown (the problem still remains though, I would have to switch back and forth for every single "frame"). Not sure if this is the exact problem of this bug, but it sure sounds similar.
please see and try comment #35 @Ruchir did you try to disable buffer_age usage?
I did try disabling buffer age usage, and I think it gave some improvement. But I don't have conclusive results yet as the problems appear only sometimes for me. Running with buffer age usage enabled now, now to get a good feeling for how often it happens, and what, if anything, might trigger it. I'll then try disabling it again to see if it really solves or mitigates it.
Can confirm the desktop freeze with Plasma 5.2.1 (frameworks 5.7) on Arch linux running kernel 3.18.6-1. It happens from time to time. Open applications: Chrome, QtCreator, Dolphin & Konsole. I can move the mouse but the keyboard does not respond anymore (CTRL-ALT-F1, ALT-SHIFT-F12, numlock, ...), neither does pressing the shutdown button.
(In reply to Bart Swennen from comment #44) > but the keyboard does not respond anymore (CTRL-ALT-F1, That's a kernel shortcut -> the kernel hangs. I doubt that yours is any related to this bug.
(In reply to Thomas Lübking from comment #45) > (In reply to Bart Swennen from comment #44) > > > but the keyboard does not respond anymore (CTRL-ALT-F1, > That's a kernel shortcut -> the kernel hangs. > I doubt that yours is any related to this bug. Correct, apologies. Note to self: learn to read! I only found one other thread reporting the same behavior: http://www.reddit.com/r/archlinux/comments/2y12pq/plasma_5_freezing_and_locking_up_the_whole/ It started when I upgraded from KDE 4 to Plasma 5.
Radeon driver? -> See eg. also https://bugs.kde.org/show_bug.cgi?id=344389 Tried to ping or ssh into the machine?
(In reply to Thomas Lübking from comment #47) > Radeon driver? > -> See eg. also https://bugs.kde.org/show_bug.cgi?id=344389 > Tried to ping or ssh into the machine? Nouveau driver The issued occured several times today: - no keyboard interaction possible - mouse works but freezes after a couple of minutes - does respond to ping - pressing the power button does nothing - see in journalctl logs that autosaves are still being done (no kernel freeze)
(In reply to Bart Swennen from comment #48) > (In reply to Thomas Lübking from comment #47) > > Radeon driver? > > -> See eg. also https://bugs.kde.org/show_bug.cgi?id=344389 > > Tried to ping or ssh into the machine? > > Nouveau driver > The issued occured several times today: > - no keyboard interaction possible Maybe just "no visual feedback"? (the cursor is directly in the framebuffer) => Try to suspend the compositor (Shift+Alt+F12), the locked framebuffer might extend to VT1 (so that Ctrl+Alt+F1 actually would work, but has no visual impact) If not and if you can ssh into the machine, do export DISPLAY=:0 xev -geometry 1920x1200 Then see whether the "broken" server still generates events (on mouse moves, clicks, keyboard - when the xev window would usually have kbd focus) > - pressing the power button does nothing Would it usually power down or logout?
Trying to suspend the compositor did nothing as my keyboard does not respond. I was able to ping the machine and perform an ssh to it. Unfortunately, the xev utility was not available. There was one line in the journalctl output that drew my attention, I noticed it before previous crashes too: Mar 29 12:30:05 obsidian kernel: nouveau E[ PFIFO][0000:01:00.0] read fault at 0x0000011000 [UNSUPPORTED_KIND] from PBDMA0/HOST on channel 0x007ee00000 [unknown] Could this be the reason for the desktop freeze? The odd thing is that under KDE4 I never had any issues with it.
"Could" - see eg. https://bbs.archlinux.org/viewtopic.php?id=155809 or http://lists.freedesktop.org/archives/dri-devel/2014-July/064589.html Because of QtQuick there's much more OpenGL invoked in plasma/5, putting the drivers under more pressure. In addition there's (possibly) glamor, which maps 2D acceleration to OpenGL.
This bug also affects Ubuntu: <https://bugs.launchpad.net/ubuntu/+source/kwin/+bug/1440210>
Please notice that comments #44-#51 focus on something (upstream) that looks like a stalled nouveau driver, impacting even input. This bug is originally about insufficient repaint events. See comment #24, comment #34 (it's now "kwin_x11 --replace" ;-) which does however not resolve for comment #41 (comment #43)
(In reply to Thomas Lübking from comment #51) > "Could" - see eg. > https://bbs.archlinux.org/viewtopic.php?id=155809 or > http://lists.freedesktop.org/archives/dri-devel/2014-July/064589.html > > Because of QtQuick there's much more OpenGL invoked in plasma/5, putting the > drivers under more pressure. In addition there's (possibly) glamor, which > maps 2D acceleration to OpenGL. No problems anymore while using the official NVidia blob.
Thomas: Yes, missing repaints sounds like what I was seeing (I'm comment #41 and #43 which you mentioned). Unfortunately I've had to go back to KDE4 because I use this laptop for work, and various crashes/misbehaviors in Plasma 5 prevented me from using it. I'm also quite busy right now so haven't had time to do any further testing. If anyone can reproduce on Intel graphics like me, and if a fix is devised and put into something I can install on Arch without compiling, I'd be happy to test it. Unfortunately all I can promise right now as work is very busy :/
Original bug report was done on intel graphics card system only.
I have the issue with ATI and not with Intel
hey, i can confirm the sudden freeze. (nearly complete death, no input possible, ie alt+tab not working, BUT mouse pointer is still working so I can move it around) here are my org.kde.KWin.supportInformation https://paste.kde.org/pkdcfnrrh i'm using intel haswell graphics (i915 driver) mesa is at version: 10.5.2 xf86-video-intel is at version: 2.99.917 x.org-x-server is at version: 1.17.1 as of now, i'm running plasma 5.2.95 on opensuse tumbleweed. the freezes started to happen after the upgrade from 5.2.1 to the 5.3-beta some additional information (I really hope they are helpful): - i switched from breeze (used before without problems) to oxygen, still getting freezes - starting plasma with compositing enabled is impossible -> the splashscreen hangs (i've waited 5 minutes, nothing happens) - starting plasma with compositing disabled works as expected, ie plasma starts, but freezes start to happen shortly after this. - the trick with export KWIN_USE_BUFFER_AGE=0; kwin --replace & doesn't seem to help. - enabling compositing in the systemsettings causes the freeze, as well as sometimes "playing around" in the settings (changing from xrender to opengl, or switching between glx and egl) - killing plamashell and working with "just" an empty desktop and kwin seems to work better, though alt+f2 (to bring up krunner) is not working (this is odd, because alt+tab works); freezes don't happen that often, even less when using xrender. but they still happen occasionally. => in this situation the input kind of works: i can switch tabs by clicking with the mouse in firefox. and I can write in firefox (ie an url in the address-bar), if i try to use --replace with either kwin or xfwm, this is not working. kwin needs to be killed and then restarted. - using kwin in xfce (via kwin_x11 --replace) works. enabling compositing in the systemsettings freezes some parts of the desktop. the panel is disappearing, but "comes back" by hovering it with the mouse pointer and it disappears again. ps: i'm going to install the debug-headers to give more information.
*** Bug 339562 has been marked as a duplicate of this bug. ***
export KWIN_USE_INTEL_SWAP_EVENT=0 export KWIN_EXPLICIT_SYNC=0 export KWIN_USE_BUFFER_AGE=0 export LIBGL_DRI3_DISABLE=1 kwin_x11 --replace & In case that works, please figure ("unset FOO_BAR") which variable does it. Can you obtain supportInformation while the compositor is up? (try "sleep 30; qdbus org.kde.kwin /KWin org.kde.KWin.supportInformation", then press SHIFT+Alt+F12 to toggle the compositor and just wait a minute or so before toggling it off again)
(In reply to Thomas Lübking from comment #60) > export KWIN_USE_INTEL_SWAP_EVENT=0 > export KWIN_EXPLICIT_SYNC=0 > export KWIN_USE_BUFFER_AGE=0 > export LIBGL_DRI3_DISABLE=1 > kwin_x11 --replace & > > In case that works, please figure ("unset FOO_BAR") which variable does it. > Can you obtain supportInformation while the compositor is up? (try "sleep > 30; qdbus org.kde.kwin /KWin org.kde.KWin.supportInformation", then press > SHIFT+Alt+F12 to toggle the compositor and just wait a minute or so before > toggling it off again) - okay, here are my supportinformation with compositing enabled: https://paste.kde.org/pz43gwyyx -> took me quite a while to get there, qdbus had various time outs (when running in the plasma-session), thus I wasn't able to retrieve any info. qdbusviewer did hang as well, while the rest was responsive, so no complete freeze, just qdbus, this might be another symptom or completely unrelated.). i used "kwin_x11 --replace" in a xfce-session to be able to use qdbus. - and the environment variables don't seem to trigger any effect. i still get completes freezes. i could try to give you the gdb output, if that's of any help.
Stupid question, does this > starting plasma with compositing disabled works as expected, ie plasma starts, but freezes start to happen shortly after this. imply the "freezes" also occur *without* any compositing? About > though alt+f2 (to bring up krunner) is not working can you (w/ suspended compositor, that's hopefully unrelated) qdbus org.kde.krunner or does it time out as well?
(In reply to Thomas Lübking from comment #62) > Stupid question, does this > imply the "freezes" also occur *without* any compositing? yep! that's exaclty what it means. the freezes do happen without compositing enabled (at least that's what the kcm and qdbus are telling me ). today I noticed, that plasmashell freezes first, and kwin stays responsive for some time longer (ie. alt+tab is working). though kwin still freezes completely a bit later. (ie no alt+tab). > can you (w/ suspended compositor, that's hopefully unrelated) > qdbus org.kde.krunner > > or does it time out as well? if the freeze DID happen, I can't bring up krunner with alt+f2. if that's the case qdbus org.kde.krunner times out. but krunner is listed as a running process. also notic the following errors in the kwin output: (i forgot to report them) QXcbConnection: XCB Error 3 (BadWindow); QXcbConnection: XCB Error 9 (BadDrawable)
The xcb errors are false positives (we cannot check whether a window is gone and perform our cleanup on them nevertheless - doesn't matter except for the reported errors). Overall it sounds like the root problem is a hanging/freezing dbus server taking down everything. Can you have a look at top when the problem occurs? Maybe a process is running amok and blocks dbus?
For pot. culprits, check netstat -nxp | grep dbus (do NOT post that list anywhere unrevisited!!) overall, I doubt that you encounter /this/ bug.
Seems fixed here with: rm -rf ~/.cache/
okay. due to an unrelated issue, I had to use an old test-account. and plasma works perfectly with it. I use a different style for the controls (e.g. scroll-bars, etc.) with this second account. there might be some other differences as well. so there needs to be something wrong with the configs. i will look into the potential dbus-issue next.
(In reply to Sebastian Gruener from comment #67) > okay. due to an unrelated issue, I had to use an old test-account. and > plasma works perfectly with it. I use a different style for the controls > (e.g. scroll-bars, etc.) with this second account. there might be some other > differences as well. > so there needs to be something wrong with the configs. > > i will look into the potential dbus-issue next. okay, i looked into the dbus-stuff. top entries seem to be normal, ie. nothing that's eating up memory or cpu. the netstat command highlights just dbus-damon und dbus-lunch with various files in tmp. I don't actually know, what to look for exactly. these are the kwin-supportinfo of the user-account, that is working. https://paste.kde.org/pwayzcvm1
okay. removing ~/.cache/ does indeed solve the problem for me as well. so resolved fixed? with this workaround. or do you want do dig deeper. I did save my cache-directory in case you're interested.
it seems an issue with some lock file
Sebastian, I believe that you are experiencing different issue than this bugzilla entry is about. I'm experiencing the same symptoms as are described in first comment (Alt+Tab unfreezes the desktop) and I can confirm, that `export KWIN_USE_BUFFER_AGE=0;` solves this problem. If this is not your case I suggest opening new bugzilla.
Let me second that: I also already experienced different flavours of 'freezes' with plasma5 from kubuntu 15.04: 1. The first was related to a plasmashell sitting on a lockfile {code} [pid 4444] open("/home/hkaelber/.cache/plasma-svgelements-default_v0.9.7.lock", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE|O_CLOEXEC, 0644) = -1 EEXIST (File exists) {code} removing that file, made the freeze disappear. kwin_x11 --replace did not help. 2. On an intel atom based netbook I sometimes see freezes that don't show the locking issue and can be workarounded by kwin_11 --replace
Matteo & Sebasitan encounter sth. around https://codereview.qt-project.org/#/c/110346/ or https://git.reviewboard.kde.org/r/122549/ Totally unrelated to this bug.
(In reply to Matteo Croce from comment #66) > Seems fixed here with: rm -rf ~/.cache/ Thanks, seems it helped. I was experiencing similar issues. At some point (about several minutes after login) kde suddenly freezes. I can move mount, but it does not response to mouse clicks and (global) shortcuts, it also does not update clock.
Just a little 'me too' - on a T420 Lenovo (Intel GPU from the i7-2620M CPU @ 2.70GHz). It was essentially impossible to run for more than 3-5 minutes. Seems that picking Oxygen as style/windeco helped, but another crash came after about half a day so it can still hang. Removed cache AND did the export bla trick, see if that helps. If it does, will try to figure out which one of the two is the helpful one but that'll take time ;-)
Same shit with Kubuntu 15 and Lenovo G780. Returned back to 14.04
Did you figure which "shit" in particular, for there're now actually several completely unrelated issues (affecting different parts of the software stack; kernel, kio, kwin) mentioned here, so your comment, though not very informative, might be misadressed.
(In reply to Thomas Lübking from comment #77) I'm afraid I won't add any certainty here. I've installed Kubuntu 15 + some useful stuff + all proprietary drivers + changed window styles a bit. All as one go. At some point plasma started to freeze in ~5min after session start - only mouse works, nothing else. No any hotkeys helped. Eventually I damaged the system (by doing hard reset every freeze) and had to roll back to 14.04. When I found this recommendation (rm -rf ~/.cache) I've decided to try again. I've installed Kubuntu 15 + performed rm + some useful soft + changed composer to OpenGL 3.x + installed all proprietary drivers except Nvidea. The problem still not appeared. I can try to install NVIDEA drivers but unless problem appears just after that this give nothing as I already performed rm -rf just after installation. So I can't identify the root of the problem. Btw, when I had this problem I managed to switch back to default drivers and restore default appearance settings before freeze happened - it didn't help. Also after few hard reboots I've lost connectivity functionality - nothing except flight mode switch was in tray.
(In reply to truf from comment #78) > No any hotkeys helped. If that include SHIFT+Alt+F12, it's not the compositor freeze (this bug originally) > Eventually I damaged the system (by doing hard reset every freeze) Due to journaling filesystems, that is rather unlikely, but you may have left stale lock files around. > changed composer to OpenGL 3.x + installed all proprietary drivers except > Nvidea. "nvidia" ;-) > The problem still not appeared. So the bottom line is that after wiping the cache, the issue is gone? -> see comment #73
(In reply to Thomas Lübking from comment #79) > If that include SHIFT+Alt+F12 Yes, tried this - didn't help. >So the bottom line is that after wiping the cache, the issue is gone? -> see comment #73 Seems like that. Also - I wiped it just after first system launch. At this moment I've installed all proprietary drivers and additionally played with window appearance but couldn't make the problem to appear again.
I have had the same issue with plasma crashing. I was opening videos in vlc and then the desktop just froze. I have to wait 2-5 minutes for the alt + ctrl + F2 to take me to tty2. I tried going back to the desktop and I saw that there was a kwin crash handler open. But that had crashed as well. In tty2 kwin_x11 was listed as kwin_x11 --crashes 1. I had to kill off any kwin processes and plasma desktop and restart SDDM before I had a working desktop. I am not sure how to attach any logs since the application that was suppose to submit them also crashed.
It's not 100% clear to me in this report if it's kwin or plasmashell freezing. If plasmashell, then this is possibly a dup of bug #341951 (and https://bugs.freedesktop.org/show_bug.cgi?id=84252 )
Greetings. Not sure if I should post it here. In my case, I see CPU spikes and several seconds locks from time to time. Sometimes just sitting and doing nothing you can see a quite regular set of CPU usage, almost like a hearth beat. Simple things like using Dolphin can generate random -and very heavy- CPU spikes on every core. This behaviour can be seen equally on AMD or Intel CPUs, even if you have lots of memory. Oh, it is just Plasma 5, months ago, and now Plasma 5.3. KDE4 doesn't have this issue.
(In reply to Turbo from comment #83) > Simple things like using Dolphin can generate random -and very heavy- CPU > spikes on every core. The crucial question is "in which process", if it causes spikes in dolphin, that's a dolphin issue. There's however also bug #312919 about high cpu load caused by the qml spinner plasma-desktop shows for kio actions (and other stuff) In general, the description is too unspecific to be assigned anywhere.
Thank you for the tip. One thing I try to do (and failed) is open the System Monitor and watch the process behaviour. Sadly, I cant find an effective way to "separate" CPU threads in order to see exactly what program is doing the spike. The problem is that a I see a very low consumption in Process Table and all the cores at 100% on System Load. I have been snooping every option in System Monitor to no avail. Is there another way/program/command that I can use to see this more clearly ? Thank you again.
Ensure to show all processes, it may be a system process. (As alternative, just run "top" in konsole...)
I had the same problem. I removed my graphics card and tried the onboard graphics and no more freezing. I installed the correct Nvidia drivers for my graphics card and it now works perfectly. I found this great post on how to install the correct driver for my graphics card. http://www.binarytides.com/install-nvidia-drivers-ubuntu-14-04/
A workaround (at least fix the frozen desktop) without restarting, ending sessions, etc. is to switch to another tty (eg tty1 with CTRL-ALT-F1) and type: DISPLAY=:0 kwin_x11 --replace & When switching back to the desktop, it is seen restarting and everything is working again.
Created attachment 92730 [details] gdb examination of frozen kwin
I have found that running vlc media player crashes kwin very occasionally . I have to go a second tty and when I run htop vlc is using 100% cpu. After I have killed it I can't go back to the desktop kwin in unresponsive or I see screen tears.
This is rather unrelated - although this bug has become a general "I perceive a problem" dumpster anyway. The original report actually sounds a lot like related to bug #340294 The we have some reports which are likely related to the stale lock file bugs in KConfig & Qt: https://codereview.qt-project.org/#/c/110346/ and https://git.reviewboard.kde.org/r/122549/ Then we've complete freezes of the X11 server Finally there're some "kwin artifacts after" issues - this matches yours and I bet your right arm that you've an nvidia GPU - the invalidated vertext buffers will more likely relate to te switch to VT1 than anything else (run "dmesg | grep NVRM" and check whether it says something about unspported framebuffer consoles, but this lately was reported regardless) VLC will likely require 100% cpu because it (or rather the driver) is performing a busy wait for the next vblank signal (which is not gonna occur) The most simple resolution of invalidated vertex buffers is to restart the compositor (press SHIFT+Alt+F12 twice)
I have the same issue, but much more fast, when I'm using Firefox for anything the crash occurs in about a half hour, but if I'm using YouTube, it crashes on less than 5 minutes. I noticed that if you don't restart plasma5 the screen don't freezes and the YouTube video continues with a lot of graphic settings wrong (like brightness, contrast, etc, it occurs at a randomly time).
Hi guys, i have same issue with constant freez of whole system, i am using latest opensuse tumbleweed, and system is not usable, one thing i did find out is that if i switch in bios to use integrated intel graphic on my i7 4770 and switch hdmi cable to motherboard i did not have a single issue or freez. Hope this can help to figure it out what is problem.
Created attachment 92965 [details] GDB log of frozen kwin_x11 I get the same kind of freeze on my Lenovo B570e laptop (with Intel graphics): I can move the mouse pointer easily but the screen contents don't respond to it nor to pressing Alt+Tab.
That's interesting, stalls on an error in libxinput: Thread 1 (Thread 0x7f4f6011a7c0 (LWP 21858)): #0 0x00007f4f582f254f in pthread_cond_wait () from /lib64/libpthread.so.0 #1 0x00007f4f5b27a2e5 in _XReply () from /usr/lib64/libX11.so.6 #2 0x00007f4f5b27cc11 in _XSeqSyncFunction () from /usr/lib64/libX11.so.6 #3 0x00007f4f5b27c3ef in _XError () from /usr/lib64/libX11.so.6 #4 0x00007f4f5b279477 in handle_error () from /usr/lib64/libX11.so.6 #5 0x00007f4f5b279525 in handle_response () from /usr/lib64/libX11.so.6 #6 0x00007f4f5b27a3b9 in _XReply () from /usr/lib64/libX11.so.6 #7 0x00007f4f4bfd7ed2 in XIQueryDevice () from /usr/lib64/libXi.so.6 #8 0x00007f4f4c22df5f in QXcbConnection::xi2SetupDevices() () from /usr/lib64/qt5/plugins/platforms/libqxcb.so #9 0x00007f4f4c22f6c0 in QXcbConnection::xi2HandleHierachyEvent(void*) () from /usr/lib64/qt5/plugins/platforms/libqxcb.so #10 0x00007f4f4c22ff2b in QXcbConnection::xi2HandleEvent(xcb_ge_event_t*) () from /usr/lib64/qt5/plugins/platforms/libqxcb.so #11 0x00007f4f4c20c96d in QXcbConnection::handleXcbEvent(xcb_generic_event_t*) () from /usr/lib64/qt5/plugins/platforms/libqxcb.so #12 0x00007f4f4c20d2fb in QXcbConnection::processXcbEvents() () from /usr/lib64/qt5/plugins/platforms/libqxcb.so #13 0x00007f4f5e50037e in QObject::event(QEvent*) () from /usr/lib64/libQt5Core.so.5 #14 0x00007f4f5ed524fc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5 #15 0x00007f4f5ed575d8 in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5 #16 0x00007f4f5e4d234d in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/libQt5Core.so.5 #17 0x00007f4f5e4d5012 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib64/libQt5Core.so.5 #18 0x00007f4f5e5235a4 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () Another this to mention is MESA is on the SW rasterizer: Thread 2 (Thread 0x7f4f43fff700 (LWP 21882)): #0 0x00007f4f582f254f in pthread_cond_wait () from /lib64/libpthread.so.0 #1 0x00007f4eb1b156d3 in thread_function () from /usr/lib64/dri/swrast_dri.so #2 0x00007f4eb1b14fd7 in impl_thrd_routine () from /usr/lib64/dri/swrast_dri.so #3 0x00007f4f582ee204 in start_thread () from /lib64/libpthread.so.0 #4 0x00007f4f5fc213dd in clone () from /lib64/libc.so.6 => Is this in a virtual machine?
More info on my case: 1. CPU usage by kwin_x11 is 0.0% and doesn't go up when I'm pressing Alt+Tab or move the mouse pointer. 2. Alt+Shift+F12 does nothing. 3. There are no .lock files in ~/.cache/ (checked with "find | grep lock")
Thomas, No, it's a Gentoo Linux installation on a real laptop, not a virtual machine.
This may be important: the current Plasma5 session was started before I added my user account to the group "video", so my user account's applications could not access /dev/dri/* or /dev/fb0. However the X server runs as root.
~/.cache/ is a red herring to this bug (at least estimating from the initial report, and notably the two backtraces we have, yours w/ an error in xinput and Martins apparently hanging in the xcb event reader) - it's just that there was a popular bug in that direction that caused random freezes and many ppl. randomly attached here. I mostly wanted to know whether this is a virtual machine as that might have had impact on xinput as well. In case you worry about your GL/dri setup, I suggest to check the output of glxinfo and inspect /var/log/Xorg.0.log and on remaining issues head over to forum.kde.org for optional assistance on the system setup to not further clutter this bug w/ unrelated things ;-)
Thomas, glxinfo and /var/log/Xorg.0.log report no errors/warnings. Do you want me to create a new thread on forum.kde.org with all the information for my case? I don't get why discussing it on the forum is better than on this bug tracker?
(In reply to Alexander Potashev from comment #100) > I don't get why discussing it on the forum is better than on this bug tracker? Because, assuming there's an issue w/ your OpenGL setup (which causes invocation of the software rasterizer) this has by 99.9% chance nothing to do with this bug (which in its core might or might not be about some libxinput error, we lack details from Ruchir in this regard, but it's the best track we have), which already is a mess of unrelated posts anyway (it's de facto unfixable, because it has turned into some unspecific "something hangs" report)
With a similar hardware Lenovo Ideapad U430 Intel 4400 graphics. A reinstall on the M2 SSD drive using Sabayon (Gentoo) 4.05 kernel and KDE 4.14.9 the same issue appeared. Normally after running any native KDE application particularly Dolphin the Plasma desktop freezes soon after closing a Dolphin window or a suspend/resume cycle. The other application windows remain active. Clearing ~/.cache made some apparent improvement for a while but changing the compositing type to OpenGL 3.1 and QT graphics system to Raster seem now to be stable. The Intel graphics is normally in use.
(In reply to Ian Newton from comment #102) > With ... KDE 4.14.9 Whatever you spotted is likely unrelated. This bug is reported on KDE 5, the stale lockfile issue is a Qt5 problem and Haswell (your chip) isn't nearly similar to ironlake (while they may of course have similar driver bugs) In case *only* the desktop froze, it's a problem with plasma-desktop. --- PS: i think we need to dissolve and close this bug - it's become a pointless mess of random "something doesn't work" reports what notoriously attracts just more unrelated reports (because noone can reasonably say what this bug is about)
I experience this issue randomly on Fedora 22. I am using a Lenovo Ideapad Z570 laptop with an Intel Core i5-2410M CPU and integrated graphics card. I am pretty sure the issue is plasmashell because 'killall plasmashell; plasmashell' gets it working again.
I experience this problem on Arch. Linux kernel 4.0.7-2, plasma 5.3.2-1
Solution in comment #34 works for me.
Solution in comment #34 DOES NOT WORK for me. And I noticed the following: during the first few seconds after the screen freezes (may be around 3 to 10 seconds), when I move mouse pointer it changes shape according to what it under it (for example, "I" when hovering text). Also, during these first seconds of freezing I can (blindly) click UI components or use key combinations and they work, although the content on the screen does no change. For example, if I was listening to music in a tab in Google Chrome, I can press Ctrl+W and the music stops playing. Of course there are no visual consequences in closing the tab, because the screen has frozen.
And after those few seconds?
(In reply to Thomas Lübking from comment #109) > And after those few seconds? Thomas, After these seconds the mouse pointer shape freezes too, so I can only move the mouse and see the pointer moving, but no other effects of this motion.
sounds af if first kwin and later on, random clients get stalled (or the x event queue turns garbage) can you please try: export KWIN_USE_INTEL_SWAP_EVENT=0 # only affects intel IGPs export KWIN_EXPLICIT_SYNC=0 # most likely candidate on nvidia GPUs export KWIN_USE_BUFFER_AGE=0 # well, you tried, but hey ... ;-) kwin_x11 --replace &
Whenever I unlock my screen after it being locked for a few minutes, the KDE panel and desktop is frozen. I cannot click on the desktop or side panel to task switch. Alt-tab works. I have to force-kill and re-launch plasmashell from another terminal.
Here is the console output of one plasmashell session from start to frozen: file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. trying to show an empty dialog trying to show an empty dialog trying to show an empty dialog trying to show an empty dialog trying to show an empty dialog trying to show an empty dialog trying to show an empty dialog trying to show an empty dialog file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. trying to show an empty dialog trying to show an empty dialog trying to show an empty dialog trying to show an empty dialog file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.systemtray/contents/ui/StatusNotifierItem.qml:131:13: QML Image: Failed to get image from provider: image://icon/ file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/lib64/qt5/qml/QtQuick/Controls/Button.qml:110:17: Unable to assign [undefined] to QObject* file:///usr/lib64/qt5/qml/QtQuick/Controls/Button.qml:100: TypeError: Cannot read property of null file:///usr/lib64/qt5/qml/QtQuick/Controls/Button.qml:89: TypeError: Cannot read property 'effectivePressed' of undefined file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/lib64/qt5/qml/QtQuick/Controls/Button.qml:110:17: Unable to assign [undefined] to QObject* file:///usr/lib64/qt5/qml/QtQuick/Controls/Button.qml:100: TypeError: Cannot read property of null file:///usr/lib64/qt5/qml/QtQuick/Controls/Button.qml:89: TypeError: Cannot read property 'effectivePressed' of undefined file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/share/plasma/plasmoids/org.kde.plasma.pkupdates/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling. file:///usr/lib64/qt5/qml/QtQuick/Controls/Button.qml:110:17: Unable to assign [undefined] to QObject* file:///usr/lib64/qt5/qml/QtQuick/Controls/Button.qml:100: TypeError: Cannot read property of null file:///usr/lib64/qt5/qml/QtQuick/Controls/Button.qml:89: TypeError: Cannot read property 'effectivePressed' of undefined Failed to find KNotification for dbus_id 16
Please notice that while this bug is now a random collection of unrelated problems, issues with the plasmashell process are misreported here for sure, so please file a bug against plasmashell. I doubt that any of the konsole output is relevant, but if it systematically happens after resuming from STR: do you have an nvidia GPU (and use the nvidia driver)?
(In reply to Thomas Lübking from comment #114) > Please notice that while this bug is now a random collection of unrelated > problems, issues with the plasmashell process are misreported here for sure, > so please file a bug against plasmashell. > > I doubt that any of the konsole output is relevant, but if it systematically > happens after resuming from STR: do you have an nvidia GPU (and use the > nvidia driver)? I'm on an intel hybrid "[AMD/ATI] Venus PRO [Radeon HD 8850M / R9 M265X]" lshw says the diver is currently i915 (lsmod confirms)
I found the cause of my desktop freezing. When I had the compositor set to use opengl3.1 it caused segfaults. libQt5Sql would segfault or libnvidia-opengl would segfault. If vlc was opened then the whole desktop would freeze. This is when running a Nvidia 9 series card (GTX 980 in my case) with the non-free driver and changing the opengl version that the compositor uses. (settings -> Display -> Compositor -> Rendering Backend)
Same issue here, with Fedora 22, When it freeze I go to tty2 and type DISPLAY=:0 kwin_x11 and it works again, how can I deal with this issue?
My case: Linux xxxxxxxxx 4.2.1-1-ARCH #1 SMP PREEMPT kdeplasma-addons 5.4.1-1 (and plasma 5 is the same, I think) Plasma hangs always if comp is on more then 24 hours. Sometime it hangs in a day, and after Ctrl-Alt-BS I see kdeinit5 crash and core dump.
Whatever the issue was for me, it has been fixed in Plasma 5.4.
I can also say, that on my machine with Plasma 5.4 (Fedora 22) it is not happening anymore.
Created attachment 94794 [details] Full list of the update to version 4.1
(In reply to Be from comment #120) > Whatever the issue was for me, it has been fixed in Plasma 5.4. attachment 94794 [details] shows full list of update to ver. 4.1 Plasma hangs every night - at the morning I have to go to the text screen and reboot comp.
e-e-e-e, pardon me, version 5.14.0
If you can move to another VT it's unlikely required to reboot the system. First try to suspend the compositor (SHIFT+Alt+F12), notably if *everything* hangs (visually, you can actually inspect the condition of random processes from the other VT) If that "helps", resume it (same shortcut), obtain the output of qdbus org.kde.KWin /KWin supportInformation and file a new bug. Be reminded that this bug will *never* fix since it turned into a random "something doesn't work" report mess.
(In reply to Thomas Lübking from comment #125) > If you can move to another VT it's unlikely required to reboot the system. > First try to suspend the compositor (SHIFT+Alt+F12), notably if *everything* > hangs (visually, you can actually inspect the condition of random processes > from the other VT) > > If that "helps", resume it (same shortcut), obtain the output of > qdbus org.kde.KWin /KWin supportInformation > and file a new bug. > > Be reminded that this bug will *never* fix since it turned into a random > "something doesn't work" report mess. Only graphic desktop is hangs, mouse pointer is live and Ctrl-Alt-Fn switches to console 'n'.
that's still unspecific, because it's not clear wheter a (all) clients do not repaint or are entirely stalled or the compositor doesn't update or is stalled. if shift+alt+f12 works only the compositor doesn't update, if not, it either doesn't respond or the issue is in the clients ("applications", including the desktop shell) or X11. For any progress, it's crucial to localize the problem - it's not possible to fix symptoms.
(In reply to Thomas Lübking from comment #125) > Be reminded that this bug will *never* fix since it turned into a random > "something doesn't work" report mess. Which is why I stopped using KDE, opting for LxQT.
(In reply to Thomas Lübking from comment #125) > If you can move to another VT it's unlikely required to reboot the system. > First try to suspend the compositor (SHIFT+Alt+F12), notably if *everything* > hangs (visually, you can actually inspect the condition of random processes > from the other VT) > > If that "helps", resume it (same shortcut), obtain the output of > qdbus org.kde.KWin /KWin supportInformation > and file a new bug. > > Be reminded that this bug will *never* fix since it turned into a random > "something doesn't work" report mess. At the morning screen is blank (screensaver), mouse move open desktop as a picture. SHIFT+Alt+F12 doesn't work, qdbus answers "Error: org.freedesktop.DBus.Error.NoReply Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network c onnection was broken." That's because of KDE: if I log off at evening, at the morning I can log in and all's working.
(In reply to EMR_Kde from comment #128) > > Be reminded that this bug will *never* fix since it turned into a random > > "something doesn't work" report mess. > Which is why I stopped using KDE, opting for LxQT. Because KDE users sometimes flood a bug with so many unrelated "I have a problem as well" comments that at some point nobody can say what the problem in the bugreport actually is? The first 24 comments are a valid bug, the rest started to mess up things with every post. Sorry. Comment #56 seems to indicate it was a problem with the intel driver, maybe then still used by default intel swap events. And if you're not using KDE, what the heck are you doing here?
(In reply to SinClaus from comment #129) > At the morning screen is blank (screensaver), mouse move open desktop as a > picture. SHIFT+Alt+F12 doesn't work, qdbus answers > "Error: org.freedesktop.DBus.Error.NoReply > Did not receive a reply. Possible causes include: the remote application did > not send a reply, the message bus security policy blocked the reply, the > reply timeout expired, or the network c > onnection was broken." That sounds as if the kwin_x11 process stalled, but if the screen is locked, it's expectable that SHIFT+Alt+F12 doesn't work (all input is grabbed by the screen locker which might be the troublemaker here) ==> does this also happen if you do *not* lock the screen with suspending to ram?? If yes, check if kwin_x11 running and not just sigstopped ("ps ax | grep kwin_x11" lists it with "TN" instead of "SN") If it is, gdb into it to obtain a backtrace on the location where it's stalled. Howto do that (using ssh is preferable, to not alter the inspected system by changing to another VT) https://community.kde.org/KWin/Debugging
(In reply to Thomas Lübking from comment #131) > (In reply to SinClaus from comment #129) > > > That sounds as if the kwin_x11 process stalled, but if the screen is locked, > it's expectable that SHIFT+Alt+F12 doesn't work (all input is grabbed by the > screen locker which might be the troublemaker here) > > ==> does this also happen if you do *not* lock the screen with suspending to > ram?? > > If yes, check if kwin_x11 running and not just sigstopped ("ps ax | grep > kwin_x11" lists it with "TN" instead of "SN") > If it is, gdb into it to obtain a backtrace on the location where it's > stalled. > > Howto do that (using ssh is preferable, to not alter the inspected system by > changing to another VT) > https://community.kde.org/KWin/Debugging I don't know how other Linux, but in Arch we don't have screen lock, it's it was simple screen off. Because hangs only plasma, I can switch to another VT.
My issue is not a "screen lock" either, just plasmashell locking up as the original bug & title state. I can still task switch, VT switch, use my programs, etc. just the desktop and panels+widgets are non-op & plasmashell has to be force-killed and re-launched.
The original bug was *not* about the plasmashell process, but the entire session (unless suspending the compositor what in return made everything but the plasmashell desktop responsive at least, I suspect an intel driver issue, but we never figured it. Notably Ruchir stated that "Alt+Tab" would "fix" it) @SinClaus The screenlocker is unrelated to the kernel or the distro, but part of the ksmserver process (KDE feature) - I don't know the default behavior for STR, but it /can/ activate with it. To check whether your session is locked, try export DISPLAY=:0 qdbus org.freedesktop.ScreenSaver /ScreenSaver GetActive
I've unchecked "start composer on system start", and it seems that system is working next day. Here is answer (through ssh) qdbus org.kde.KWin /KWin signal void org.kde.KWin.reloadConfig() method Q_NOREPLY void org.kde.KWin.cascadeDesktop() method int org.kde.KWin.currentDesktop() method Q_NOREPLY void org.kde.KWin.killWindow() method void org.kde.KWin.nextDesktop() method void org.kde.KWin.previousDesktop() method Q_NOREPLY void org.kde.KWin.reconfigure() method bool org.kde.KWin.setCurrentDesktop(int desktop) method bool org.kde.KWin.startActivity(QString) method bool org.kde.KWin.stopActivity(QString) method QString org.kde.KWin.supportInformation() method Q_NOREPLY void org.kde.KWin.unclutterDesktop() signal void org.freedesktop.DBus.Properties.PropertiesChanged(QString interface_name, QVariantMap changed_properties, QStringList invalidated_properties) method QDBusVariant org.freedesktop.DBus.Properties.Get(QString interface_name, QString property_name) method QVariantMap org.freedesktop.DBus.Properties.GetAll(QString interface_name) method void org.freedesktop.DBus.Properties.Set(QString interface_name, QString property_name, QDBusVariant value) method QString org.freedesktop.DBus.Introspectable.Introspect() method QString org.freedesktop.DBus.Peer.GetMachineId() method void org.freedesktop.DBus.Peer.Ping()
That sounds like a stalled kwin process. Please file a new bug and there attach the output of qdbus org.kde.KWin /KWin supportInformation (obtain it while the compositor is running "ok" - you can toggle the compositor anytime with SHIFT+Alt+F12) Also, if possible obtain and attach a backtrace for the stalled kwin process, according to https://community.kde.org/KWin/Debugging (but first just file the bug with teh information instantly available)
(In reply to Thomas Lübking from comment #136) > That sounds like a stalled kwin process. > > Please file a new bug and there attach the output of > qdbus org.kde.KWin /KWin supportInformation > > (obtain it while the compositor is running "ok" - you can toggle the > compositor anytime with SHIFT+Alt+F12) > > Also, if possible obtain and attach a backtrace for the stalled kwin > process, according to https://community.kde.org/KWin/Debugging > > (but first just file the bug with teh information instantly available) OK, I'll try make it in a monday.
I've open new Bug 353587
Time to treat this. Plasma becoming almost unusable. Get repeated nouveau cache read errors which will hang the system. Could be disk-oriented, may not.
If you've a specific error, please file a new bug and log the errors there. *This* bug is meanwhile a mess of random "somthing doesn't work" reports (full /var, corrupted plasma theme caches, whatnot else) and can thus never be treated nor fixed.
Hi Thomas, I think this report should then be closed as invalid. Comments in this thread (useful information) should be splitted into separate reports. Because this report here serves nothing but a garbage bin. BTW, for me the issue described in name is solved: first I used a workaround KWIN_USE_BUFFER_AGE=0, then the issue dissapeared completely (not using the workaroud now).
On Monday 26 October 2015 22:36:29 you wrote: > KWIN_USE_BUFFER_AGE=0 How do you use this?
> KWIN_USE_BUFFER_AGE=0 As I said, I do not use this anymore. However, what I used in the past was: $ cat > /etc/profile.d/kwin-fix.sh export KWIN_USE_BUFFER_AGE=0 $ chown root:root /etc/profile.d/kwin-fix.sh $ chmod 0644 /etc/profile.d/kwin-fix. sh
On Tuesday 27 October 2015 08:27:53 Kirill Bogdanenko via KDE Bugzilla wrote: > https://bugs.kde.org/show_bug.cgi?id=338999 > > --- Comment #143 from Kirill Bogdanenko <kirill.bogdanenko@gmail.com> --- > > > KWIN_USE_BUFFER_AGE=0 > > As I said, I do not use this anymore. However, what I used in the past was: > > $ cat > /etc/profile.d/kwin-fix.sh > export KWIN_USE_BUFFER_AGE=0 > > $ chown root:root /etc/profile.d/kwin-fix.sh > > $ chmod 0644 /etc/profile.d/kwin-fix. sh Works so far. Only get the buffer errors from a "smart-notifier" on kde start up. None from iceweasel so far (which was I prime offender). So far, so good.
On Tuesday 27 October 2015 08:27:53 you wrote: > https://bugs.kde.org/show_bug.cgi?id=338999 > > --- Comment #143 from Kirill Bogdanenko <kirill.bogdanenko@gmail.com> --- > > > KWIN_USE_BUFFER_AGE=0 > > As I said, I do not use this anymore. However, what I used in the past was: > > $ cat > /etc/profile.d/kwin-fix.sh > export KWIN_USE_BUFFER_AGE=0 > > $ chown root:root /etc/profile.d/kwin-fix.sh > > $ chmod 0644 /etc/profile.d/kwin-fix. sh Or ,,, maybe spoke too soon. Got these from iceweasel: [ 2758.941564] nouveau E[ PFIFO][0000:01:00.0] CACHE_ERROR - ch 18 [iceweasel[6983]] subc 5 mthd 0x0180 data 0xbeef0301 [ 2758.941579] nouveau E[ PGR][0000:01:00.0] ERROR nsource: ILLEGAL_MTHD nstatus: PROTECTION_FAULT Interesting. See how harmful these are.
See eg. http://forums.fedoraforum.org/archive/index.php/t-247253.html Please notice that nouveau has nowhere production quality reg. OpenGL - Plasma 5 with its pleathora of GL contexts is likely just "too much". Unless you've a very strong reason (unsupported HW) resort to the nvidia blob. Otherwise I suggest to avoid OpenGL as much as possible (ie. disable HW acceleration in firefox etc, use xrender compositing) in case of troubles. And ensure to run recent kernel and mesa versions (not stable/reliable at all, but likely less static bugs)
Created attachment 95164 [details] attachment-15798-0.html Most probably correct, except did not have problems until recent Sid upgrades. Situation is getting worse, cannot even get plasmashell up without a freeze, writing this on a live CD. I suspect this was from the disk, but if that cache is on a disk, it is not on the suspect disk, and I am beginning to suspect smartctl more than the disks.I would like to get back up, make sure xrender is chosen and disable all desktop effects. Should be better behaved.The kwin fix was OK until I rebooted, then plasmashell would not start so removed the file. Probably based on an older version in any event.----- Original Message -----From: Thomas Lübking via KDE Bugzilla <bugzilla_noreply@kde.org>Date: Tuesday, October 27, 2015 3:52 pmSubject: [kwin] [Bug 338999] [unspecific] Desktop freezes time to time on plasma 5 (collection of various unrelated problems, WONTFIX)To: d_baron@012.net.il> https://bugs.kde.org/show_bug.cgi?id=338999> > --- Comment #146 from Thomas Lübking > <thomas.luebking@gmail.com> ---> See eg. http://forums.fedoraforum.org/archive/index.php/t-247253.html> > Please notice that nouveau has nowhere production quality reg. > OpenGL - Plasma> 5 with its pleathora of GL contexts is likely just "too much".> Unless you've a very strong reason (unsupported HW) resort to > the nvidia blob.> Otherwise I suggest to avoid OpenGL as much as possible (ie. > disable HW> acceleration in firefox etc, use xrender compositing) in case of > troubles.And ensure to run recent kernel and mesa versions (not > stable/reliable at all,> but likely less static bugs)> > -- > You are receiving this mail because:> You are on the CC list for the bug.
Sorry for the mess. Must remember to specify plain text each time (not default) in the provider's mail site. Suggestion to simply remove /.cache? This is on a maybe problematic disk. I would assume if this is being used, KDE would just make a new one. Since 1. The system-settings item to turn off compositing, select xrender, itself, freezes things so I cannot get to it, and 2. I will sometimes not even get far enough in plasmashell start up to do alt/shift/F12 at least -- is there any way I can set these manually so all KDE sessions will default this way?
I tested extensively in OpenSUSE 42.1 which comes with Plasma 5.3. Most KDE applications freeze for 30 seconds when you start them. It is not only kate or okular. It is dophin and many others. This happens on my desktop system on which I have a Nvidia Quatro 620 semi professional video card. I have the same system on a laptop with an Intel HD video chip and this problems do not occur. I this thing pissed me off so I did more research and I figured out that if you change the window manager from kwin5 to something else, for example Openbox, the problem goes away, There is obviously a problem Kwin5 has with the Nvidia driver (I have the proprietary one) There is no need to keep this unconfirmed just because you don't have an NVIDIA card and can't reproduce it.
(In reply to bogdan from comment #150) I apologize, Opensuse 42.1 comes with plasms 5.4.3
Problem with the bug is the unspecificity (is that a word?). The problem is Nvidia and Nouveau. I solved it, as recommended, by using the proprietary driver. Guess what? If it were not freezing up, I would go back to Nouveau. Flash (OK, time to ditch that!) and Vimeo malfunction or do not work at all. The only thing that is really better with Nvidia's own is flightgear and I do not have enough room for it anyway. > https://bugs.kde.org/show_bug.cgi?id=338999 > > bogdan@hlevca.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |bogdan@hlevca.com > > --- Comment #149 from bogdan@hlevca.com --- > I tested extensively in OpenSUSE 42.1 which comes with Plasma 5.3. > Most KDE applications freeze for 30 seconds when you start them. It is not > only kate or okular. It is dophin and many others. > > This happens on my desktop system on which I have a Nvidia Quatro 620 semi > professional video card. > > I have the same system on a laptop with an Intel HD video chip and this > problems do not occur. > > I this thing pissed me off so I did more research and I figured out that if > you change the window manager from kwin5 to something else, for example > Openbox, the problem goes away, There is obviously a problem Kwin5 has with > the Nvidia driver (I have the proprietary one) > > There is no need to keep this unconfirmed just because you don't have an > NVIDIA card and can't reproduce it. > > --- Comment #150 from bogdan@hlevca.com --- > I tested extensively in OpenSUSE 42.1 which comes with Plasma 5.3. > Most KDE applications freeze for 30 seconds when you start them. It is not > only kate or okular. It is dophin and many others. > > This happens on my desktop system on which I have a Nvidia Quatro 620 semi > professional video card. > > I have the same system on a laptop with an Intel HD video chip and this > problems do not occur. > > I this thing pissed me off so I did more research and I figured out that if > you change the window manager from kwin5 to something else, for example > Openbox, the problem goes away, There is obviously a problem Kwin5 has with > the Nvidia driver (I have the proprietary one) > > There is no need to keep this unconfirmed just because you don't have an > NVIDIA card and can't reproduce it.
The problem is NOT the Nouveau driver. I have the proprietary one and I still have the 30 seconds freezing problem when I start a KDE application. There are no issues for non KDE applications. The problem, as I already mentioned in my original message, is kwin with any driver for Nvidia. As soon as I changed the window manager to Openbox ( you can change it in System settings Applications -> Default Application) the problem disappeared. Of course some KDE functionality is lost. In addition Plasma 5 crashes in different circumstances, most related to power management, but these issues are reported in different places and are not related to kwin, it happens with Openbox as well. (In reply to David Baron from comment #152) > Problem with the bug is the unspecificity (is that a word?). > The problem is Nvidia and Nouveau. I solved it, as recommended, by using the > proprietary driver.
IPORTANT NOTICE: *this* bug entry has long tiem turned a completely poinless mess of various "something does not work" reports on contradicting problem descriptions - often not even KWin related (plasmashell hangs for corrupted cache and whatnot issues) => I'll now close it as WONTFIX. Please abort it completely. Do not post on it. Not even to confirm this stance (to keep this message on top) If you've continuing problems and believe they're related to KWin (whether as window manager or compositor), please open a NEW bug with an exact description of your problem and have us triage them. Ruchir, I'm very sorry that this happened. If your original problem persists, please just re-file it. Sorry again.
At the moment we have kwin 5.5.1, but every morning I see that my working comp hangs after screen saver is over. "kwin_x11 --replace" reanimate comp.
bug #353587 won't fix with any KDE release, it's a bug in XLib. And please stop commenting on *this* bug, see comment #154
OK, but I can't understand why this bug in XLib don't affect with KDE 4.
not kde4, qt4. it's - very likely - due to combined xcb and xlib usage and on top of that happens in xinout2. none of that used in qt4. closing seems required. sorry.
*** Bug 359489 has been marked as a duplicate of this bug. ***