Comment 96 for bug 330824

2.5GB of memory, fairly high disk used (~85%), I can reproduce nearly at will.

The bisect I performed above may have only found a patch that makes
things significantly worse: when running a kernel from the 'good'
side of the bisect I still get occasional lockups (on the order of 2-4
days), compared to minutes otherwise. It almost seems that in that
case, concurrent activity is a necessary case: firefox's periodic
session saving (rewriting a 400kb file), starting audio playback,
running a gnome-shell build with io at idle priority, and installing a
package was the triggering state the last time I had a 'good' kernel
lock up.