I had similar symptoms and it turned out that baloo_file_extractor is producing a lot of IO load during which the system stalled. I worked around the problem by calling `balooctl disable` and `balooctl stop`.
If not, still calling `iotop` in a terminal might be helpful to see if during the freeze some big IO is blocking the system.

Otherwise, is it still possible to switch to the text terminal? E.g. try `ctrl-alt-f1`.

- baloo is running prior to the KDE freeze, but does not seem to be the problem:

~> balooctl status
Baloo File Indexer is running
Indexer state: Idle
Indexed 11 / 11 files
Current size of index is 140.00 KiB


- After freeze and CTL-ALT-F1, top processes in terms of CPU and memory are Web Content and Firefox.

- Killing either the Web Content or Firefox processes (kill -9) and running "init 5" from root gets me back to my LIGHTDM login, but then networking is not functional after launching Plasma 5 -- this might be an unrelated issue, since KDE was not restarted normally in this after-freeze case.

- Leaving the Web Content process running, I can't seem to get back to Plasma 5 without rebooting the machine.

- Logging in with GNOME, however, everything works normally, including networking -- to reiterate, Leap 42.2 does not freeze at all running GNOME/Cinnamon.

- This is happening on a Lenovo ThinkPad T400 (x86_64) -- I have been unwilling to test on my primary laptop.

- The freeze sometimes does not take long when actively using the machine -- sometimes it takes longer -- other times it does not occur at all -- seems random, but I'm sure there are a definite set of variables that have yet to be identified -- it occurs frequently and unpredictably enough on this machine that Leap 42.2/KDE is unusable. 

- I suspect a memory management issue of some sort, possibly involving both Firefox and Plasma 5 -- but I have no proof at this point -- the behavior does seem to be that of a piece of code stepping on display memory.

- Free memory on this machine is as follows and shows plenty available -- however this was taken when the machine was NOT freezing up:

~> free
             total       used       free     shared    buffers     cached
Mem:       1941732    1708548     233184     107428      59884     636192
-/+ buffers/cache:    1012472     929260
Swap:      2107388       1300    2106088

I did not have "iotop" installed when the machine was freezing on me earlier.  I will restore my previous test image, install that package and try to reproduce another system hang.

After getting another freeze and running iotop, I see nothing unusual in terms of disk I/O and nothing related to Baloo.  I notice, however, that memory is heavily utilized and there is only 2G of memory on this machine.  On the other hand, I have run all versions of plasmashell versions prior to 5.8.x without problems.  Leap 42.2 GNOME also has no issues.

The problem does *seem* to be Firefox on Plasma 5.8.x.  After escaping to a command prompt, it really seems like I need to kill either the Web Contect or Firefox process before I can successfully get a root prompt and "init 5" to the GUI.

After a fresh install and update of Leap 42.2, there seems to be no freezing issue.  I believe the issue might be related to the specific version of Firefox that happened to be on the install that was freezing.  That version had the following package:

MozillaFirefox-50.0.2-42.2.x86_64


The recently installed version, without the problem, had the following package:

MozillaFirefox-50.1.0-45.1.x86_64


This bug should be closed, as I am unable to identify a specific problem related to openSUSE itself.

(In reply to Nolan Leasy from comment #5)
> ...
> This bug should be closed, as I am unable to identify a specific problem
> related to openSUSE itself.

On the contrary, this bug should not be closed,
because no application should be allowed to freeze the desktop.

> On the contrary, this bug should not be closed, because
> no application should be allowed to freeze the desktop.

Agreed.  I have not been able to replicate the freeze since I re-installed and updated Leap 42.2, but it's more of a Plasma 5.8 issue than openSUSE per se.

I did back up the image of the problematic install, prior to re-install, in case the KDE team needs anything in terms of logs or configuration.  I strongly suspect, however, that it might be a memory management issue of some sort.  My wild guess would be that Plasma 5.8 is allowing an application such as Firefox to write to display memory.

Let me know if you need anything more on my end.  Thanks!

Dear all,

I have also encountered the same issue. I use Tumbleweed and these are my specs:

KDE: 5.8.4
Kernel: 4.8.14-1

What i have already managed to find during google search was that there is an issue with Intel Graphic cards and KDE. KDE freezes randomly when for example just editing a document with libreoffice or when searching in chrome or firefox. I don't know where to search for possible cause as journalctl -xe do not show any error. Any info / log needed please feel free to ask.

I can confirm the above-mentioned issue of a randomly freezing KDE Plasma 5 desktop on a fresh openSUSE Leap 42.2 installation, with AMD graphics card. I never encountered this problem with openSUSE Tumbleweed. What additional information is needed?

Adding the repos "KDE Frameworks 5" and "Qt5" to the openSUSE Leap 42.2 ones, as described on https://en.opensuse.org/KDE_repositories#KDE_Frameworks_5_.26_Plasma_5, solved the issue for me.

After Upgrading to Leap 42.2 we had also seen 2 times this window manager freeze on a system with integrated Intel HD 4600 graphic. I couldn't say if this bug is specific to an integrated Intel graphic because most of my desktop systems are running on Leap 42.1 without any kde problems. 
As described in the other comments a replace of the window manager in a terminal (kwin_x11 --replace) brings the desktop back to work.
No error log is present. It seems that kwin_x11 process is blocking.
There are also some old bug reports in the last years about kde display freezes (also in kde4).
Some hints are saying to disabling all display effects or replacing the kwin with another stable windowmanager like openbox.
Sorry that i can only give some workarounds, but nothing for analyzing the original bug.
I've seen another bug report about KDE 5.8 , which seems to address the same problem : https://bugzilla.opensuse.org/show_bug.cgi?id=1014831 .

I encounter a very similar problem on a Lenovo T460s with KDE running Leap 42.2. In my case, running multiple monitors seems to make the problem occur more frequently. Both the laptop monitor and second display turn blank before freezing, and it is not possible to change to a separate console using CTRL+ALT+F1. A power cycle is required to make the computer responsive.

(In reply to Matthew Mah from comment #12)
> Both the laptop monitor and second display turn blank
> before freezing, and it is not possible to change to a separate console
> using CTRL+ALT+F1. A power cycle is required to make the computer responsive.

This means that it is a bug in the kernel driver. Reassigning.

Please check whether the issue happens with openSUSE Leap 42.2 GA kernel, i.e. kernel-default-4.4.27.  There can be a regression in the recent backport patches.

... also test the latest kernel in OBS Kernel:openSUSE-42.2 repo, too.

But it's weird that the machine becomes not responsive.  Usually such a GPU hang up doesn't lead to the complete machine lock up, and the remote access is often available.

In anyway, try to set up kdump to see if there is anything we can catch.  Basically without a crash log, or any evidence of the kernel crash, it's impossible to analyze.

If no kernel crash (or any other crash) log is found, the only way is to bisect -- supposing it's a regression.  But, this requires a way to reproduce the bug in 100% reliably.  Can you reproduce the issue quickly and reliably at every boot?

Hi Takashi,

I was never able to reproduce the problem reliably.  It seemed entirely random, although there must have been variables that I was not able to isolate.  The only thing I saw upon escape to the console was a moderately high level of Firefox and Web Content CPU consumption.

I never found any pertinent log information, but perhaps was not looking in the right place.  I agree that this is going to be difficult or impossible to analyze.

I had to restore my image from that time and, for what it's worth, the kernel version was as follows when the freezing/hanging occurred:

uname -r
4.4.36-5-default

I would also reiterate that Firefox at the time was a "dot-oh" version.  I mention this only because that was the only real activity at the time of the hang.

firefox --version
Mozilla Firefox 50.0.2


However, I am currently using an updated version of Leap 42.2 KDE and the following kernel on which I HAVE NOT EXPERIENCED ANY FREEZING OR HANGING ISSUES.  Firefox has since advanced to version 50.1.

uname -r
4.4.36-8-default

firefox --version
Mozilla Firefox 50.1.0

*** Bug 1021444 has been marked as a duplicate of this bug. ***

I also cannot reproduce this issue reliably. 

I do see it without use of Mozilla Firefox. 

Today, I tried the following kernels versions and had lock up problems with both:
4.4.27 (GA)
4.4.44-1.gf887322-default (OBS Kernel:openSUSE-42.2)

I have also seen the display only freeze, rather than go blank first and then freeze.  

The Lenovo T460s with this problem has (from YaST2 hardware information):
Intel HD Graphics 520
Device Identifier (spec): 74291
Device Identifier: 71598
Revision 7

I just wanted to mention that I hit this frequently with the KDE desktop in Leap 42.2 and thought it was a KDE issue so I reinstalled with Gnome 3.20.2 but experience it in both environments. My setup is a Lenovo Thinkpad x260 with an Intel(R) HD Graphics 520 (Skylake GT2) with a 1080p monitor connected via mini-displayport to HDMI (ie. laptop <> minidp <> hdmi <> monitor). My monitor is configured as the secondary display oriented above my main display. It happens once a day on average.

Please let me know if there's any logging or debug info I can provide to support this bug.

(In reply to Anthony Hughes from comment #19)
> I just wanted to mention that I hit this frequently with the KDE desktop in
> Leap 42.2 and thought it was a KDE issue so I reinstalled with Gnome 3.20.2
> but experience it in both environments. My setup is a Lenovo Thinkpad x260
> with an Intel(R) HD Graphics 520 (Skylake GT2) with a 1080p monitor
> connected via mini-displayport to HDMI (ie. laptop <> minidp <> hdmi <>
> monitor). My monitor is configured as the secondary display oriented above
> my main display. It happens once a day on average.
> 
> Please let me know if there's any logging or debug info I can provide to
> support this bug.

Sorry, I forgot to mention that I do not experience this in Ubuntu 16.04 nor Fedora 25, in case it's relevant.

Has anyone experienced this on something other than a Lenovo Thinkpad?

The common thread might be the Thinkpad video driver(s) in Leap 42.2.  I've been using Leap 42.2 (KDE) on an HP ProBook 4430s for a couple of months now with no issues.

The test machine where I encountered this problem was a Lenovo Thinkpad T400.

(In reply to Nolan Leasy from comment #21)
> Has anyone experienced this on something other than a Lenovo Thinkpad?
> 
> The common thread might be the Thinkpad video driver(s) in Leap 42.2.  I've
> been using Leap 42.2 (KDE) on an HP ProBook 4430s for a couple of months now
> with no issues.
> 
> The test machine where I encountered this problem was a Lenovo Thinkpad T400.

The duplicate bug is reported for Dell hardware.

Hi!

On my 42.2 system I see more or less the same problem.
Screen freezes, mouse works. Luckily I can switch back to tty1 and inspect
the system state.
As it seems kwin_x11 deadlocks. Killing it and starting it again renders my desktop back in a good state.

Here some infos I collected from the locked up kwin_x11 process:
Task states: (it blocks on poll an futex)
 
[<ffffffff81219d80>] poll_schedule_timeout+0x50/0x80
[<ffffffff8121b317>] do_sys_poll+0x3a7/0x510
[<ffffffff8121b53d>] SyS_poll+0x5d/0xe0
[<ffffffff8160f772>] entry_SYSCALL_64_fastpath+0x16/0x71
[<ffffffffffffffff>] 0xffffffffffffffff

[<ffffffff81219d80>] poll_schedule_timeout+0x50/0x80
[<ffffffff8121b317>] do_sys_poll+0x3a7/0x510
[<ffffffff8121b53d>] SyS_poll+0x5d/0xe0
[<ffffffff8160f772>] entry_SYSCALL_64_fastpath+0x16/0x71
[<ffffffffffffffff>] 0xffffffffffffffff

[<ffffffff81101122>] futex_wait_queue_me+0xd2/0x160
[<ffffffff811020aa>] futex_wait+0x16a/0x250
[<ffffffff81103ba0>] do_futex+0xe0/0x590
[<ffffffff811040be>] SyS_futex+0x6e/0x150
[<ffffffff8160f772>] entry_SYSCALL_64_fastpath+0x16/0x71
[<ffffffffffffffff>] 0xffffffffffffffff

[<ffffffff81219d80>] poll_schedule_timeout+0x50/0x80
[<ffffffff8121a793>] do_select+0x5b3/0x770
[<ffffffff8121ab21>] core_sys_select+0x1d1/0x2f0
[<ffffffff8121acfb>] SyS_select+0xbb/0x100
[<ffffffff8160f772>] entry_SYSCALL_64_fastpath+0x16/0x71
[<ffffffffffffffff>] 0xffffffffffffffff

[<ffffffff81101122>] futex_wait_queue_me+0xd2/0x160
[<ffffffff811020aa>] futex_wait+0x16a/0x250
[<ffffffff81103ba0>] do_futex+0xe0/0x590
[<ffffffff811040be>] SyS_futex+0x6e/0x150
[<ffffffff8160f772>] entry_SYSCALL_64_fastpath+0x16/0x71
[<ffffffffffffffff>] 0xffffffffffffffff

Open fds:
lr-x------ 1 rw users 64 Jul  7 09:44 0 -> pipe:[26001]
l-wx------ 1 rw users 64 Jul  7 09:44 1 -> /home/rw/.xsession-errors-:0
lrwx------ 1 rw users 64 Jul  7 09:44 10 -> socket:[26174]
lrwx------ 1 rw users 64 Jul  7 09:44 12 -> socket:[26183]
lrwx------ 1 rw users 64 Jul  7 09:44 13 -> anon_inode:[eventfd]
lrwx------ 1 rw users 64 Jul  7 09:44 14 -> /dev/dri/card0
lr-x------ 1 rw users 64 Jul  7 09:44 15 -> anon_inode:inotify
lr-x------ 1 rw users 64 Jul  7 09:44 17 -> anon_inode:inotify
l-wx------ 1 rw users 64 Jul  7 09:44 2 -> /home/rw/.xsession-errors-:0
lrwx------ 1 rw users 64 Jul  7 09:44 3 -> anon_inode:[eventfd]
lrwx------ 1 rw users 64 Jul  7 09:44 4 -> anon_inode:[eventfd]
lrwx------ 1 rw users 64 Jul  7 09:44 5 -> socket:[25525]
lrwx------ 1 rw users 64 Jul  7 09:44 6 -> anon_inode:[eventfd]
lrwx------ 1 rw users 64 Jul  7 09:44 7 -> anon_inode:[eventfd]
lrwx------ 1 rw users 64 Jul  7 09:44 8 -> socket:[25526]
lrwx------ 1 rw users 64 Jul  7 09:44 9 -> socket:[26167]

GPU:
00:02.0 VGA compatible controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display (rev 0c)

What else infos do you need? It happens here every few days...

I have the same issue on Tumbleweed (KDE frozen except for mouse). I have observed it on my workstation and home laptop.

BTW: Just happened also on my new Thinkpad T470p on LEAP 42.3.

I just experienced this on a Thinkpad T450 running a fresh snapshot of Tumbleweed and the MATE DE.  Everything froze completely on me and I wasn't even able to CTL-ALT-F3 to a command line.  I had to hard boot the machine.

My system information:

nsleasy@t450:~> cat /etc/os-release 
NAME="openSUSE Tumbleweed"
# VERSION="20180219"
ID=opensuse
ID_LIKE="suse"
VERSION_ID="20180219"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20180219"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"

nsleasy@t450:~> uname -r
4.15.4-1-default
nsleasy@t450:~> 


I am still wondering if this is some sort of memory management issue related primarily to Thinkpad hardware.  Most of the postings on this bug seem to be from Thinkpad users.  I have never experienced this on my HP ProBook 4430.

If there are specific system logs somewhere that I might provide, please let me know, but I suspect this is a situation where logs would not be useful.

I have a problem that may be related:
Opensuse Leap 15.0 fresh install on Thinkpad T420s which has both Intel and nVidia graphics. I didn't have problems on 42.2 and 42.3 but started seeing problem about a month ago. 

After some use (web browsing, doxbox) or after resuming from sleep the clicks on k-menu and window decorations do nothing, win-key does not open k-menu and also right click no longer brings a menu. If I restart X or kill all my processes from virtual console and log back in it works. At first I thought it was nVidia driver issue. From the start I was using only nVidia GPU with Intel disabled in BIOS.  I tried older and different nVidia drivers. Then I thought it was thermal issue and blew the dust. Then I tried disabling nVidia GPU and enabling Intel only. At this point the system runs much cooler - 50C when idle, which is normal in summer for a thin laptop. I tried clean install with nothing from any non-official repos and after some time the taskbar, menu and maximize buttons become non-responsive.

Seems common pattern here is Plasma and Thinkpad.

Compaq presario CQ61, 4 Gb
Dual boot window 7 and leap 15
sanpper disabled, zypper snapper plugin not installed

since update from 42.3 to leap 15

random gui slow down or freeze

during freeze there are many many disk accesses.

phenomenon occurs  till 1 to 10 mn

phenomenon occurs whenusing an app
can occur with Firefox, kmail, digikam. i use them frequently.

i assume this : 
 swap problem
- swap "0 M used" => no problem
- swap "400 M used" => problem
or

baloo problem

or 

something else

Just a note: It turned out on my Thinkpad T420s the faulty / problematic trackpad was causing the problems. After disabling trackpad in BIOS the problem disappeared. I'm not 100% certain my problem was the same as other people's but they could see if disabling trackpad makes any difference.

PC
intel i5 4590, 4 cores, 3.30 GHz
8 Go memory
snapper disabled, zypper snapper plugin not installed

For the very first time i encounter the same problem with 42.3: gui slows down or freeze.

same case as 15.0 :

- swap is used : 1.4 Go
- many disk accesses

this time i saw that kswapd0 was working and is among the 10 processes most using CPU

this problem is a random and cycling problem. delay between 2 occurences is  about 30 s if you use FF and change frequently the web page and duration of freeze is 1 or 2 mn

Leap 42.3 reached EOL.  If you still have a same problem on the newer distros, please create a new entry.  Thanks.