I've pushed addition checks from the dri WAIT_FOR_EVENT handling as they didn't appear to negatively impact my machine:
commit 272d1c14a39c32ade39b5a8b080a891f2b3d6e8e
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Jul 9 10:41:19 2010 +0100
video: apply the crtc box checks from dri.
The dri code is much more careful in ensuring that the scan lines that
is waits for are valid. Copy this code to video, with a bit of work this
can be refactored, and perhaps even teach dri how to handle rotated
front buffers.
References:
Bug 28964 - [i965gm] GPU infinite MI_WAIT_FOR_EVENT while watching video
in Totem
https://bugs.freedesktop.org/show_bug.cgi?id=28964
However, these are just a set of extra sanity checks. It is not clear under what circumstances the machine froze so I cannot say whether this is the fix for the bug.

commit 85345517fe6d4de27b0d6ca19fef9d28ac947c4a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sat Nov 13 09:49:11 2010 +0000
drm/i915: Retire any pending operations on the old scanout when switching
An old and oft reported bug, is that of the GPU hanging on a
MI_WAIT_FOR_EVENT following a mode switch. The cause is that the GPU is
waiting on a scanline counter on an inactive pipe, and so waits for a
very long time until eventually the user reboots his machine.
We can prevent this either by moving the WAIT into the kernel and
thereby incurring considerable cost on every swapbuffers, or by waiting
for the GPU to retire the last batch that accesses the framebuffer
before installing a new one. As mode switches are much rarer than swap
buffers, this looks like an easy choice.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28964
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29252
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org