Weird rawhide desktop behavior

[stan]

On Sat, 24 Mar 2012 11:58:15 -0600
Jonathan Corbet <corbet-ft at lwn.net> wrote:

> Here's a strange pathology that just bit me for the first time in a
> while, though I've seen it before.  I'm not sure where to file a bug
> on this one...
> 
> In short: I'll be working away, minding my own business, when the
> desktop goes completely dead - no response to any key or mouse
> events.
...
> Anybody got a clue what's going on, or where I could look to get more
> information?

This is old, and might be unrelated, but I used to have these lockups
starting around F11,F12.  For me, it was almost always firefox related,
I had just clicked on something, and bingo, lock-up.  But it was other
things often enough that I couldn't say for sure it was firefox. So I
started compiling my own kernels, customized for my system.  And the
problem went away, and I haven't seen it again.  Maybe it is gone in the
generic kernels, maybe not, but it only takes about 10 to 15 minutes of
my time now to compile and install a kernel, so I just continue doing
it.  Such lockups only happened while X was running for me, and that
would seem to absolve the kernel.  So it is probably that the recompile
removes the troublesome code, or changes it enough that it no longer
fails.

My best guess at the time was that there was a race condition leading
to a deadlock.  One other thing you could try is boosting the priority
of your user to -1.  It seems counter-intuitive, but for a workstation
instead of a server, this makes sense because then your graphical user
experience doesn't get impacted by background processes as much, yet
they still run if you have any CPU time (most of the time).  It is
in /etc/security/limits.conf, and as I said I have my user set to -1.
This is especially important to prevent system io from affecting your
gui experience as much. Think of it this way; is it more important to
your user experience that writing log files get done, or that the file
you want to edit gets loaded?  It also might finesse the race condition
leading to your lockups, by shifting the priorities of jobs in the
interrupt chain.