KDE session hanging issues on Fedora 17

[Duncan]

Nikhil bhalwankar posted on Sun, 22 Jul 2012 03:43:11 +0800 as excerpted:

> I have 64 Bit Fedora Core 17 installed on my DELL Inspiron 15R laptop. I
> am facing laptop freezing issues intermittently when I login using
> during KDE session. Can anybody please help me on this?

That's not a lot of information to go on... but a few questions:

When posting to a kde list, keep in mind that people run kde on all sorts 
of distributions.  I use gentoo, here.  And just as you likely haven't 
the foggiest idea what version of kde (or much else) I'm running when I 
say gentoo (which doesn't really have distro releases as it's a rolling 
distribution with weekly snapshot install media), I haven't much of an 
idea what version of kde (or the kernel, or xorg-server, or...) you're 
running when you say fedora core 17.

And on a kde list, the kde version especially useful.  So... what kde 
version?  (If you can't get into the kde GUI to see, from the about 
dialog, you can run say, "konsole --version" from a text-based login or 
from gnome terminal or whatever.  Or query your package manager for it.)


Meanwhile, as I said, that's not a lot to go on, but sometimes I've had 
similar issues tied to faulty graphics (OpenGL).  So a bit of information 
about your graphics stack (hardware, proprietary or freedomware driver 
with version, xorg-server version, mesa version, kernel version) might 
help.

Do you have a desktop environment / window manager other than kde 
installed?  Do the freezes happen in it as well as in kde?

Assuming you can get into kde (you say the freezes are intermittent) for 
long enough to check, in kde system settings under desktop effects, on 
the general tab, are desktop effects enabled (enabled at startup, if your 
kde version is new enough)?  If you disable them, does the issue go 
away?  If disabling them entirely helps but you want effects, you can 
also try leaving them enabled, but on the advanced tab, try xrender 
instead of opengl compositing, or with opengl, uncheck the use opengl 2 
shaders (again, I think that's a somewhat newer option) option.

When the freezes happen, is it still possible to switch to a text vt 
using for instance ctrl-alt-f1 ?  If not, assuming your distro enables 
the magic-sysrequest keys, do they still work?  (Sysrequest requires 
holding the alt key and hitting printscreen/sysrequest, then hit the key 
for your desired function.)  Alt-srq-k should kill X (if you're not 
frozen, be sure everything's saved before you do this).  Actually, it 
terminates any running program on that virtual terminal and returns you 
to the text prompt, or for X, which runs in a VT of its own, to a blank 
screen.  (You could then use ctrl-alt-f1 to get to a text console and 
login or shutdown from there.)

The alt-srq-key sequence, where key is in sequence r,e,i,s,u,b should 
force a (partially clean) system reboot.  R forces the keyboard out of 
Raw "X" mode, E nicely asks running apps to tErminate, I will kIll any 
that didn't terminate nicely... which should leave you at a text prompt 
if the system's responding normally.  S forces an emergency Sync of all 
unwritten data back to disk...

You can actually use alt-srq-s to sync disks at any time.  I use it 
before I do something I know is risky and that might lockup the system, 
to be sure everything to that point is saved.

Up to the S, you still have a running system, at a text prompt.  Don't do 
the last two unless you really do appear to be frozen.

U tells the kernel to remoUnt all mounted filesystems read-only, assuming 
it isn't too scrambled to safely do so.  If the kernel thinks it's 
scrambled, it won't do anything, to avoid writing scrambled data to the 
disk.  In most cases, if the kernel isn't scrambled, you'll see the disk 
activity light blink when you do the S and the U, as it syncs and safely 
remounts read-only.

B tells the kernel to reboot, unconditionally, no syncing or saving data 
(thus the S and U before it).  Even if the kernel doesn't trust itself to 
write to disk, if it's not entirely off in never-never-land, it'll 
reboot.  Thus, if alt-srq-b doesn't force a reboot (and you know magic-srq 
is on for your kernel), the kernel is entirely gone.


In addition to forcing a reboot, this sequence also gives you a hint at 
how bad the freeze was.  If ctrl-alt-f1 lets you switch to VT1 without 
issue, then it's likely that switching back to X (ctrl-alt-f7, normally, 
since X is traditionally run on vt7) and waiting a bit will solve the 
problem.  If that does nothing but alt-srq-k kills X, the problem was 
worse, but you still might be able to recover from a text console, and if 
not, the reisub should at least save some of your data.  Similarly if alt-
srq-r then lets you switch to a text VT (ctrl-alt-f1 or whatever).

If those minor things don't work, continue with the eisub sequence.  If 
the S and U give you disk activity, then userland was mostly/entirely 
dead but the kernel was still alive and sane enough to at least save some 
data.

If the S and U don't do anything but B does reboot, then the kernel was 
alive but damaged enough that it didn't trust itself to write to disk any 
longer.  That's pretty bad.

If even alt-srq-b doesn't respond, your kernel's entirely dead, the 
system fully frozen.  If you're getting this sort of thing often, it's a 
pretty sure indication of one of two things:  Either X and your graphics 
stack isn't working well on your hardware and is corrupting the kernel 
(X, because of the privs it has to have to efficiently work with 
graphics, can more easily than most apps corrupt the kernel), or your 
hardware is likely defective.  The latter can be due to bad memory, a 
faulty CPU, a bad power supply (either from the wall or the computer 
power supply unit that converts wall power for use by the computer), or a 
bad motherboard chipset, among other things.

Of course if it's the hardware, other desktop environments will likely 
show the problem as well, tho perhaps not the the same degree as some 
work the hardware harder than others.  As for the graphics stack, KDE 
with OpenGL effects, especially with OpenGL shaders active, stresses that 
more than most desktop environments, tho OpenGL based games use it even 
more.  That's why the questions about other DEs and whether turning off 
effects helpe.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.