Bug 27115

Created attachment 34127 [details]
Xorg.0.log

Created attachment 34128 [details]
i915_error_state

Decoded by intel_error_decode at http://launchpadlibrarian.net/41062268/IntelErrorDecode.txt . I find two things interesting:
1. ACTHD: 0x116179c8 which is outside any of the buffers.
2. IPEHR: 0x01800002 since I have seen a lot of MI_WAIT_FOR_EVENT "Display Pipe A/B Scan Line Window Wait Enable" in this register at other bug reports on i965 and GM45 lately.

I'm the original bug filer over at Ubuntu launchpad 516909.

I'm at your disposal to try new kernels, patches, etc.  Please provide enough detail/links to howto's when replying --- I've only started messing with kernels, options, PPAs, etc recently.

Adding myself to CC: list.

Thanks

Keith

(In reply to comment #2)
> Created an attachment (id=34128) [details]
> i915_error_state
> 
> Decoded by intel_error_decode at
> http://launchpadlibrarian.net/41062268/IntelErrorDecode.txt . I find two things
> interesting:
> 1. ACTHD: 0x116179c8 which is outside any of the buffers.

Looks like we are reading the wrong register for Active Head on Ironlake when grabbing error state.

> 2. IPEHR: 0x01800002 since I have seen a lot of MI_WAIT_FOR_EVENT "Display Pipe
> A/B Scan Line Window Wait Enable" in this register at other bug reports on i965
> and GM45 lately.

Similarly, I know there has been a lot of poking in this area in order to set up event triggering. Reassigning to a more knowledgeable person.

Based on a lot of similar automatic bug reports for Ubuntu, the currently active batchbuffer is probably:

0x0e043000:      0x09000000: MI_LOAD_SCAN_LINES_INCL
0x0e043004:      0x000004b0:    dword 1
0x0e043008:      0x09000000: MI_LOAD_SCAN_LINES_INCL
0x0e04300c:      0x000004b0:    dword 1
0x0e043010:      0x01800002: MI_WAIT_FOR_EVENT
0x0e043014:      0x54f08806: XY_SRC_COPY_BLT (rgb enabled, alpha enabled, src tile 1, dst tile 1)
0x0e043018:      0x03cc0680:    format 8888, dst pitch 1664, clipping disabled
0x0e04301c:      0x00000000:    dst (0,0)
0x0e043020:      0x04b00640:    dst (1600,1200)
0x0e043024:      0x04781000:    dst offset 0x04781000
0x0e043028:      0x00000000:    src (0,0)
0x0e04302c:      0x00000680:    src pitch 1664
0x0e043030:      0x0bb98000:    src offset 0x0bb98000
0x0e043034:      0x02000000: MI_FLUSH
0x0e043038:      0x00000000: MI_NOOP
0x0e04303c:      0x05000000: MI_BATCH_BUFFER_END

and the correct value for ACTHD is 0x0e043014. There are many bug reports downstream with a hang in this kind of batch buffer on GM45 and 965GM, and ACTHD is always 0x.....014.
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/539804
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/539538
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/537874
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/535218
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/535010

Yakui,

Is there any additional information you might need to fix this?  Other things I can try?

Thanks
Keith

Please see https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/516909/comments/58

It seems upgrading to the 2.6.32-19.28 kernel fixes my problem.

I've run testing with it for 3-4 days, and everything is much improved.

Please change the status as appropriate.

Thanks

Keith

(In reply to comment #7)
> It seems upgrading to the 2.6.32-19.28 kernel fixes my problem.

The patch that is included in 2.6.32-19.28 (with 2.6.33.1 drm + patches) and was intended to fix this is 

  [ Jesse Barnes ]
  * SAUCE: drm/i915: don't change DRM configuration when releasing load
    detect pipe

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=0d2907f4bead56cff60f91068b3a3efa7149e702

I haven't seen this being applied upstream in linux-2.6.33.y or linux-2.6 git trees.

(In reply to comment #7)
> Please see
> https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/516909/comments/58
> 
> It seems upgrading to the 2.6.32-19.28 kernel fixes my problem.
> 
> I've run testing with it for 3-4 days, and everything is much improved.
> 
> Please change the status as appropriate.
> 
> Thanks
> 
> Keith

thanks for the updating. So this bug will be marked as resolved.