Bug 22225

Created attachment 26659 [details]
dmesg output

Created attachment 26660 [details]
intel gpu dump, post freeze

I'm afraid I had to bzip2 this as it's too big for bugzilla

Created attachment 26661 [details]
Full lscpi output for my system

Created attachment 26662 [details]
Backtrace of hung X session

It looks like the ioctl is not completing. I assume the fact the address is post ioctl when I use GDB is because the ioctl does exit with EAGAIN and libc will re-attempt the ioctl when restarted.

I'm afraid I didn't have debug symbols at the time. I'll try and re-create once I've rebuilt the DRM component.

Correction: The monitor is attached to TMDS-1, VGA is connected but turned off

09:03 alex@danny/x86_64 [video_freeze.report] >xrandr 
Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 2048 x 2048
VGA connected (normal left inverted right x axis y axis)
   1440x900       59.9 +
   1280x1024      75.0     60.0  
   1280x960       60.0  
   1152x864       75.0  
   1024x768       75.0     70.1     60.0  
   832x624        74.6  
   800x600        72.2     75.0     60.3     56.2  
   640x480        75.0     72.8     66.7     59.9  
   720x400        70.1  
TMDS-1 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 459mm x 296mm
   1680x1050      59.9*+
   1280x1024      75.0     60.0  
   1280x960       60.0  
   1152x864       75.0  
   1024x768       75.0     70.1     60.0  
   832x624        74.6  
   800x600        72.2     75.0     60.3     56.2  
   640x480        75.0     72.8     66.7     59.9  
   720x400        70.1  

Created attachment 26702 [details]
Backtrace with debug symbols

This is the backtrace with debug symbols. You can see the problem is the system is getting stuck in DRM_IOCTL_I915_GEM_SET_DOMAIN

Created attachment 26705 [details]
Dmesg after the X system has hung

I enabled the DRM debugging in the kernel and got this voluminous output of the hang. It seems the system is stuck waiting for an object to complete.

Created attachment 26706 [details]
Dmesg after the X system has hung

I enabled the DRM debugging in the kernel and got this voluminous output of the hang. It seems the system is stuck waiting for an object to complete.

Comment on attachment 26706 [details]
Dmesg after the X system has hung

Hmm not sure what happened there.

OK my dmesg.after seems to have been corrupted by the reboot. However it was showing the a loop forever as it waited for a GEM object to become free. I can re-generate if needed.

There have been several fixes to the syncing code since 2.7.1:

commit 128c1c3b7d57b157604788f82bf9fd389839068f
Author: Carl Worth <cworth@cworth.org>
Date:   Wed Apr 29 14:43:56 2009 -0700

    Use libdrm to lookup pipe for tear-free sync of XV

commit 04772b6c09a88f0483c2a7efc48029967c77b9bc
Author: Keith Packard <keithp@keithp.com>
Date:   Thu May 14 16:57:11 2009 -0700

    If DRM can't figure out which pipe to sync on, then don't sync at all.

commit 34660fd2df5d61b77ed7041d32ac29053fc94f5a
Author: Eric Anholt <eric@anholt.net>
Date:   Fri May 15 23:21:05 2009 -0700

    Only sync XV to vblank when drawing to the frontbuffer.

If it still occurs with xf86-video-intel from master (or .902 if you're not doing rotation), please reopen.

I tried testing with 2.7.99.902 without success. X won't even start:

X: i830_batchbuffer.h:59: intel_batch_start_atomic: Assertion `!pI830->in_batch_atomic' failed.

As a guess, you were using 2.7.99.902 with some later broken changes on top, not actually 2.7.99.902.

(In reply to comment #13)
> As a guess, you were using 2.7.99.902 with some later broken changes on top,
> not actually 2.7.99.902.
> 

Possibly but the Gentoo ebuild was only carrying 3 patches, all from the tree:

b74bf3f9a65af9e72921d4e9028d9d4d023f8bc6 - Fix XV scan line calculation when rotated.
e386e7b14b139f15205e14b173e8222bf38d9e18 - Reset framebuffer offset when rebinding aperture (22760)
a1e6abb5ca89d699144d10fdc4309b3b78f2f7a9 - Use batch_start_atomic to fix batchbuffer wrapping problems with 8xx render.

When I asked on intel-gfx is was suggested the assert was fixed in the latest build so I was waiting for the next snapshot release to test. Unfortunately I've never been able to get a working git build so I'm kinda stuck with testing snapshots where I can roll back quickly to get a working system (the machine is my main desktop).

The only one that looks as though it might trigger it is a1e6abb... I'll have a go testing with a plain 2.7.99.902 when I get back to the machine.

Ok testing with latest drm-next:

08:20 alex@danny/x86_64 [~] >uname -a
Linux danny 2.6.31-rc2-intel-drm-01085-g2a2430f #23 SMP Thu Jul 23 08:06:25 BST 2009 x86_64 Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz GenuineIntel GNU/Linux

And latest x11-drivers/xf86-video-intel-2.8.0

I now have working KMS with switching to and from full/screen video :-)

The only minor cosmetic problem is the GDM screen (and final placement of Gnome taskbars) is confused. Gnome seems to think the screen is 3/4 the size it is actually displaying. However I can raise another bug for that.