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.
