[kde-linux] KDE4 and Nvidia 7000M
1i5t5.duncan at cox.net
Tue Jul 7 14:12:50 UTC 2009
Jonathan <jhhummel at bigpond.com> posted 1244463904.21714.96.camel at mistress,
excerpted below, on Mon, 08 Jun 2009 22:25:04 +1000:
> Essentially, when it does look up, it will keep playing and shuffling
> music in amarok fine, (On that point, I know this is not the right
> place, but why is amarok a spelling mistake in evolution?) Even if I am
> printing, it will finish all spooled documents correctly (a big thing on
> my old colour inkjet printer - again what's with the spell check?!)
I think that's what's called a "live-lock". The system is still alive in
the background, but your video and etc is all locked up.
Spelling: amarok isn't a standard word in whatever language you've
selected, so it's flagged as a bad spelling. I don't do evolution, but
in many apps if you right-click on the "misspelled" word, it'll give you
a number of choices to "fix" it, plus a choice to add it to your custom
dictionary. I find myself doing that quite often with various technical
terms, names like konqueror, etc.
Similarly, color/colour, one or the other will be wrong depending on
which English variant you've chosen (colour is flagged here, en.US, as I
grew up in the former English colony Kenya, I'm familiar with the en.gb
spelling for many words too), and inkjet is likely to be wrong, as it's
still a technical term, not found in the standard dictionary that the
spellchecker uses. So you add it to your custom dictionary as you're
sure that's correct if technical domain spelling, and it shouldn't flag
it the next time.
Meanwhile, back to the "live-lock". If you have a second machine
networked to the first, with a remote login available, if it's a live-
lock, you can usually login and kill X, reset the console, etc.
Even if you don't, as long as your kernel was built with the Magic-SysReq
key functionality, you can sometimes recover, and if not recover, at
least use its kernel access to shut the system down somewhat more gently,
unmounting drives and etc before you reboot, thus lessoning the chance of
lost data and/or and fsck.
For the details, see either the sysrq.txt file in your kernel
documentation dir (which may be /usr/src/linux/Documentation/sysrq.txt,
depending on your distribution and their layout, and whether you have
kernel sources installed), or google it. However...
Do these before you lock up:
1) Check that you have /proc/sys/kernel/sysrq. If you don't, it's not
compiled into your kernel. Try a different kernel or learn how to
compile your own.
2) Check that the value of that file is 1. If it's 0, it's disabled and
you'll have to enable it by writing 1 to the file (as root of course, as
it's a system parameter). (If the value is > 1, it serves as bit-flags
on which specific MagicSRQs are allowed. See the documentation for
echo 1 > /proc/sys/kernel/sysrq
(You can set that to run in a startup script if you'd like.)
Then when you live-lock, and even if it appears to deadlock, you can try
this. The sequence is (a) hold down Alt, (b) hold down the SysRq
(PrintScr) key, (c) hit the appropriate letter, below.
1) To see if you can get back to a text mode VT to recover:
a) unRaw: Alt-Srq-R
b) Try to switch to a VT: Ctrl-Alt-F1 (or other function key
corresponding to the VT you want to switch to)
If that works, you can login at the CLI, kill X, clean up anything that X
dumped if you like, then restart X and KDE, or whatever. IOW, you're
back in business.
If that doesn't work, then you should try the following emergency reboot
sequence, as it could save you some lost data and/or and fsck, as
compared to a hard reset. It may or may not work, depending on whether
the kernel's locked up or still alive at least enough to do this, but
it's worth a shot:
2) Safe reboot sequence:
a) sigtErm: Alt-Srq-E
(This is optional. It tells any apps that are still working enough to do
so to shut down nicely... if they can. Except for init.)
b) sigkIll: Alt-Srq-I
(Again, optional. The kernel force-kills all remaining apps except for
c) Sync: Alt-Srq-S
This is an emergency sync. Note that this one comes in handy by itself
at times, if you want to make sure something vital has synced to disk, or
are about to do something that you know might cause a crash. If you do
it by itself, that is, not as part of this sequence, it should be
entirely safe, tho depending on your filesystem and cache parameters, it
might take a bit to flush all cached writes to disk.
d) remoUnt ro: Alt-Srq-U
This remounts all filesystems read-only, thus ensuring all kernel buffers
are flushed and everything properly written to the disk.
e) reBoot or shutdOwn: Alt-Srq-B or Alt-Srq-O
This does what it says. If you use these by themselves, the kernel
reboots/shuts-down IMMEDIATELY, no syncing, no nothing. That's why the
above sequence is recommended.
If you note, the critical three are SUB, or all of them together,
REISUB. If you remember at least the SUB sequence and use it, you'll
very possibly save yourself a lot of grief, compared to the alternative
of simply hard rebooting.
Of course, it doesn't always work. Even if the kernel is still alive, if
it thinks it might be scrambled enough that it doesn't trust itself to
properly write to the disks, it'll refuse to do the S and U bits, and
only the B/O will work. If it's hard-locked, even that won't work and
you'll have to do the hard reset-thing.
Actually, if the hardware is scrambled bad enough, and I've had this
happen a few times here, even a quick hardware reset won't work. You'll
have to hit the power button for the four seconds to have the hardware
shut it down (or simply unplug), and let it sit for a few minutes, off.
Half an hour should work, but by the time I get to that point, I'm
usually ready to call it a day/night anyway, and leave it shutdown for
several hours. That fixes it, unless the hardware is blown.
But anyway, especially when you get into those live-lock situations,
remember REISUB. It could very well save you some serious pain.
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
More information about the kde-linux