Created attachment 24921 [details] Xorg.0.log Xserver locks up whenerver I try to play a video using Xv using totem or gxine. With mplayer -vo xv playback works until I change to fullscreen mode. It is impossible to switch to a Console with Ctrl-Alt-F1, even after killing the X-Server with Alt-SysRq-K. This happens only with KMS enabled. Video playback using Xv with UXA and KMS *disabled* works fine. System environment: -- chipset: G33 -- system architecture: 64-bit -- xf86-video-intel: 2.7.0 -- xserver: 1.6.1 -- mesa: 7.4 -- libdrm: 2.4.9 -- kernel: 2.6.30-rc2 -- Linux distribution: Debian squeeze/sid -- Machine or mobo model: Intel DG33TL -- Display connector: DVI
I'm experiencing this on my laptop with 945GM - with some videos toggling fullscreen results in a freeze. It only happens with some videos and seems to be related to their aspect ratio - the freeze never happens with widescreen videos (16/9), but always with 4/3 and 40/33 (and maybe some others). Also it only happens when external VGA monitor is enabled, never when only LVDS is on. I'm using xserver 1.6.1 xf86-video-intel a8a771a853478e5f45f71d0eff3c4d55bf24d0ad mesa 7.4.1 kernel 2.6.30-rc4 libdrm 2.4.9
Created attachment 25585 [details] Output of intel_gpu_dump sorry about gzipping, but bugzilla complained about its size.
Do -vo x11 works fine ?
(In reply to comment #3) > Do -vo x11 works fine ? > yes, x11 and gl work normally.
This is likely fixed by keithp's commit: commit 8255cca2c9092f7ecb798944aa8f03fa3efcfa6c Author: Keith Packard <keithp@keithp.com> Date: Fri May 1 18:34:43 2009 -0700 Split i915 textured video commands to fit into batch buffers. i915 textured video commands are quite long, but must be contained in the same batch buffer as the 3D setup commands. When the number of clip rects for the video becomes too large for the associated commands to fit in the same batch buffer, this change breaks the sequence into pieces, ensuring that each batch contains the necessary setup sequence. on the master branch (also cherry-picked to the 2.7 branch). Do you have that in your checkout? If not, please give it a try. thanks, Kristian
(In reply to comment #5) > This is likely fixed by keithp's commit: > > commit 8255cca2c9092f7ecb798944aa8f03fa3efcfa6c > Author: Keith Packard <keithp@keithp.com> > Date: Fri May 1 18:34:43 2009 -0700 > Just did a git pull to ensure this is included, but didn't help. But in the past I only checked with totem and gxine, which both opened their window in the topleft corner of the screen and X locked up immedaetely. I now did some testing with mplayer (-vo x11/gl/gl2 just work fine), wich opens the playback window centered on the screen and ... works. But X still locks up when I switch to fullscreen mode OR move the playback window around and hit the topmost ~110 pixels of the screen (screensize is 1680x1050).
I upgraded last weekend to kernel 2.6.30-rc6 libdrm 2.4.11 xf86-video-intel 87332a7cc16af82aa47e07fbf90da3635b071dbf haven't seen any X lockups since then.
(In reply to comment #7) > I upgraded last weekend to > > kernel 2.6.30-rc6 > libdrm 2.4.11 > xf86-video-intel 87332a7cc16af82aa47e07fbf90da3635b071dbf > > haven't seen any X lockups since then. > I can confirm this - with kernel 2.6.30-rc6, libdrm 2.4.11 and latest git of xf86-video-intel this bug no longer happens. However with 2.6.30-rc4 kernel (maybe rc5, i didn't test) any attempt to use Xv with xf86-video-intel after 87332a7cc16af82aa47e07fbf90da3635b071dbf results in an immediate freeze.
nice to hear it's fixed in the new kernel.
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.