Bug 28964

Created attachment 36858 [details]
BootDmesg.txt

Created attachment 36859 [details]
CurrentDmesg.txt

Created attachment 36860 [details]
Dependencies.txt

Created attachment 36861 [details]
GdmLog.txt

Created attachment 36862 [details]
GdmLog1.txt

Created attachment 36863 [details]
GdmLog2.txt

Created attachment 36864 [details]
Lspci.txt

Created attachment 36865 [details]
Lsusb.txt

Created attachment 36866 [details]
PciDisplay.txt

Created attachment 36867 [details]
ProcCpuinfo.txt

Created attachment 36868 [details]
ProcInterrupts.txt

Created attachment 36869 [details]
ProcMaps.txt

Created attachment 36870 [details]
ProcModules.txt

Created attachment 36871 [details]
ProcStatus.txt

Created attachment 36872 [details]
RelatedPackageVersions.txt

Created attachment 36873 [details]
UdevDb.txt

Created attachment 36874 [details]
UdevLog.txt

Created attachment 36875 [details]
XorgConf.txt

Created attachment 36876 [details]
XorgLog.txt

Created attachment 36877 [details]
XorgLogOld.txt

Created attachment 36878 [details]
Xrandr.txt

Created attachment 36879 [details]
glxinfo.txt

Created attachment 36880 [details]
i915_error_state.txt

Created attachment 36881 [details]
setxkbmap.txt

Created attachment 36882 [details]
xdpyinfo.txt

Created attachment 36883 [details]
xkbcomp.txt

batchbuffer at 0x0edac000:
0x0edac000:      0x09000000: MI_LOAD_SCAN_LINES_INCL
0x0edac004:      0x000004b0:    dword 1
0x0edac008:      0x09000000: MI_LOAD_SCAN_LINES_INCL
0x0edac00c:      0x000004b0:    dword 1
0x0edac010:      0x01800002: MI_WAIT_FOR_EVENT
0x0edac014: HEAD 0x54f08806: XY_SRC_COPY_BLT (rgb enabled, alpha enabled, src tile 1, dst tile 1)
0x0edac018:      0x03cc0780:    format 8888, dst pitch 1920, clipping disabled
0x0edac01c:      0x00000000:    dst (0,0)
0x0edac020:      0x04b00780:    dst (1920,1200)
0x0edac024:      0x08f93000:    dst offset 0x08f93000
0x0edac028:      0x00000000:    src (0,0)
0x0edac02c:      0x00000780:    src pitch 1920
0x0edac030:      0x07546000:    src offset 0x07546000
0x0edac034:      0x02000000: MI_FLUSH
0x0edac038:      0x00000000: MI_NOOP
0x0edac03c:      0x05000000: MI_BATCH_BUFFER_END

Hmm, it is interesting how more careful the dri code is in handling the MI_WAIT_FOR_EVENT.

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.

Clearing regression keyword, nothing in the report suggests that this bug has been recently introduced. If it can be narrowed down to particular commit (or range thereof) that would be most useful.

http://cgit.freedesktop.org/~ickle/drm-intel/log/?h=drm-intel-next contains a new check in hangcheck that should fix these as a last resort.

Repository moved:

git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git drm-intel-next

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