I can reproduce it easily,so will attempt a bisect. I have a 2G swap enabled and my mesa version is (I use gentoo with their x11 overlay) :
for mesa : snb-magic-12553-gb534c39
for drm : libdrm-2.4.39-16-g14db948
for xf86-video-intel : 2.20.9-43-gfb5205a (with uxa, no sna)
If you want me to try other versions, no problem.

I tried with the reverted commit, but the problem is still here.
I'm still bisecting. I did it once but don't think I was correct in doing it because it gave me a merge commit as first bad one :
commit 9db908806b85c1430150fbafe269a7b21b07d15d
Merge: 4d7127d 72f36d5
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sat Oct 13 13:22:01 2012 -0700
Merge tag 'md-3.7' of git://neil.brown.name/md
so restarting it.
but before, i'll test the fastboot branch and report.

(In reply to comment #9)
> just to be sure that this is what I have to test; I did:
>
> git clone http://cgit.freedesktop.org/~ickle/linux-2.6/ -b fastboot fastboot
>
> and have :
>
> v2.6.32-rc1-168511-g7da6bfc
>
> Is that OK ?
That's commit 7da6bfcd589270bcd35bfcf0b029403c52e5ad06
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Nov 13 11:43:29 2012 +0000
drm/i915: Only preserve the BIOS modes if they are the preferred ones
which is the tip of fastboot, so it should be fine. Just you are lacking a few tags. :)

Created attachment 70113[details][review]
disable unbound tracking
Silly me just noticed that the unbound tracking has been merged into 3.7, not 3.6. This has a big enough impact to explain all kinds of things. Please try the attached patch, thanks.

(In reply to comment #23)
> Well, after a 3 hours uptime, it didn't yet crash. So it is more stable.
> So for me, it's the first 3.7 good kernel. Thanks !
So that I know which of the many branches I labeled as bug55984 today, can you please tell me which commit you are running? Thanks.

Oh noes, wrong branch... Sorry.
Interestingly though that is my master branch from just before the merge with 3.7-rc2, so it still has all of the contentious features. However, to focus on the present, presuming you did something like:
$ git remote add ickle -f git://people.freedesktop.org/~ickle/linux-2.6
You want to do a
$ git checkout -b bug56916 ickle/bug59844
build, install, test.

i will try it asap.
I redid several bisects that pointed to
bf7ad8eeab995710c766df49c9c69a8592ca0216 is the first bad commit
commit bf7ad8eeab995710c766df49c9c69a8592ca0216
Author: Michel Lespinasse <walken@google.com>
Date: Mon Oct 8 16:30:37 2012 -0700
rbtree: move some implementation details from rbtree.h to rbtree.c
rbtree users must use the documented APIs to manipulate the tree
structure. Low-level helpers to manipulate node colors and parenthood are
not part of that API, so move them to lib/rbtree.c
it seems to not be the culprit but to expose more the bug.
The only problem I can see (not a de velopper) is that it changes
-static inline void rb_set_parent(struct rb_node *rb, struct rb_node *p)
-{
- rb->rb_parent_color = (rb->rb_parent_color & 3) | (unsigned long)p;
-}
to :
+#define rb_color(r) ((r)->__rb_parent_color & 1)
...
+static inline void rb_set_parent(struct rb_node *rb, struct rb_node *p)
+{
+ rb->__rb_parent_color = rb_color(rb) | (unsigned long)p;
+}
so changing the "& 3" to "& 1".
I tried to apply that change to a working kernel but had no crash and reverting it from 3.7 didn't make a stable kernel either.

Hm, that's a very strange bisect - at most this should effect code generation a bit and move a few functions around in the compiled kernel. But we already know that this 3.7 regression is most likely a side-effect of some seemingly unrelated change, which then brings a probably pre-existing bug up.

Created attachment 71909[details][review]
Overallocate fenced regions
So, that patch just has the effect of changing the eviction order so that cached bo are no longer preferentially thrown out. All pointing towards a latent bug elsewhere.
The error-states in https://bugzilla.redhat.com/show_bug.cgi?id=877461 follow the same pattern as I've observed with invalid surface sizes (an EU is idle waiting for the never-returning sampler, whilst all other EU are busy stalling for the shared resource). So based on that observation, let's attach surface allocation and please try the attached patch for the DDX (UXA).

(In reply to comment #36)
> Created attachment 71909[details][review] [review]
> Overallocate fenced regions
Do you want me to test it with a crashing 3.7 kernel and a 2.20.16-48-g52fd223 + patch intel driver ?
And for the 2 other patches, which one should I test now ? both together, the last one only ?

(In reply to comment #39)
> (In reply to comment #36)
> > Created attachment 71909[details][review] [review] [review]
> > Overallocate fenced regions
>
> Do you want me to test it with a crashing 3.7 kernel and a
> 2.20.16-48-g52fd223 + patch intel driver ?
> And for the 2 other patches, which one should I test now ? both together,
> the last one only ?
So far, we have a positive report for combining the xf86-video-intel patch and the kernel eviction fix, that is both of the patches from comment 37 and 38. So please try that combination first.

(In reply to comment #46)
> (In reply to comment #45)
> > Just to let you know that today I had the problem again :-(
> > Is there a way I can help you ?
>
> Was that with any of the patches discussed applied?
Yes, both the kernel and the intel driver patches were applied.

(In reply to comment #47)
> (In reply to comment #46)
> > (In reply to comment #45)
> > > Just to let you know that today I had the problem again :-(
> > > Is there a way I can help you ?
> >
> > Was that with any of the patches discussed applied?
>
> Yes, both the kernel and the intel driver patches were applied.
Which on of the two kernel patches? "make the shrinker less aggressive" and/or "drm: Only evict the blocks required to create the requested hole"?

(In reply to comment #48)
> (In reply to comment #47)
> > (In reply to comment #46)
> > > (In reply to comment #45)
> > > > Just to let you know that today I had the problem again :-(
> > > > Is there a way I can help you ?
> > >
> > > Was that with any of the patches discussed applied?
> >
> > Yes, both the kernel and the intel driver patches were applied.
>
> Which on of the two kernel patches? "make the shrinker less aggressive"
> and/or "drm: Only evict the blocks required to create the requested hole"?
Patchwork drm: Only evict the blocks required to create the requested hole

(In reply to comment #49)
> (In reply to comment #48)
> > Which on of the two kernel patches? "make the shrinker less aggressive"
> > and/or "drm: Only evict the blocks required to create the requested hole"?
>
> Patchwork drm: Only evict the blocks required to create the requested hole
Can you please test the "make shrinker less aggressive" too? Maybe on top of all the current patches.