On Sat, 24 Mar 2012 11:58:15 -0600 Jonathan Corbet <corbet-ft@xxxxxxx> 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. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
