Comment # 45 on bug 1028575 from Mircea Kitsune

Created attachment 731245 [details]
Screenshot of "top"

Lots of important new information on this freeze, which was of course ported to
the latest openSUSE Tumbleweed system packages and still works:

First and foremost, the problem does not happen in every session, and this is
not always influenced by updates! During an interval in which I installed
absolutely no relevant package changes, the following has happened: The freeze
occurred after about just 8 hours of uptime... after that I restarted the
machine, but then I had 4 days of uptime with no freeze! This leads me to
believe that certain applications or system actions prepare the system with a
"time bomb", which then causes switching between windows or desktops to produce
the freeze... however I have no way to know what mines the system and what
doesn't yet, as I use too many applications at once to figure out which might
be responsible.

Anyway another crash happened today. Once more I quickly hit Control + Alt + F1
to switch to a different runlevel; This caused the image to become corrupted on
the monitor, however the system remained responsive and didn't actually freeze.
So I went to my mother's computer and logged in via SSH, which indeed still
worked. I was able to issue a reboot command, which caused the image to briefly
unfreeze as the monitor turned on and off a few more times... I could see a few
KDE error messages about applications crashing, before the system actually went
ahead and rebooted successfully! However this is only possible if I switch to a
console quickly enough when noticing the freeze start to happen, if not the
whole machine freezes and not even SSH responds from other devices!

While I was in SSH, I decided to run "top" and take a screenshot of my
processes (while the computer was frozen and with corrupt image stuck on the
screen). I can't tell if anything is out of the ordinary such as a memory leak,
but I'm attaching a screenshot of it here.