[kde-linux] KDE4 and Nvidia 7000M

[Duncan]

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 
details.)

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 
init.)

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