Comme=
nt # 31
on bug 10030=
6
from MirceaKitsune
Created attachment=
132448 [details]
Screenshot of "top"
Lots of important new information on this freeze, which was of course porte=
d 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 fre=
eze
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 deskt=
ops 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 mig=
ht
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 corrupte=
d on
the monitor, however the system remained responsive and didn't actually fre=
eze.
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 bri=
efly
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 l=
eak,
but I'm attaching a screenshot of it here.