Created attachment 26658 [details] Xorg log with Mode Debug enabled Running with KMS enabled X will hang when I attempt to fullscreen an mplayer/totem video playing. It seems to be stuck in an ioctl in libdrm. -- chipset: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) -- system architecture: x86_64 -- xf86-video-intel: 2.7.1 -- xserver: 1.6.1.901-r3 -- mesa: 7.4.2 -- libdrm: 2.4.11 -- kernel: 2.6.30-rc8-intel-drm-00023-g34c8638 (intel-drm-next tree) -- Linux distribution: Gentoo -- Machine or mobo model: Efficient PC ASUS (ICH7) -- Display connector: LVDS/DVI Reproducing steps: Play a video with mplayer and hit "f" to full screen the display Additional info: I noticed that the GDM start-up looks a little odd. While full screen is enabled the graphics only fit in the top left 3/4s of the screen as though GDM is confused about the screen resolution.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.