Created attachment 18358 [details] The xorg.conf in use An Ubuntu-User filed this bug on Launchpad: If I play a video file with any video player(totem, mplayer, vlc), the X server crashes. The whole screen colors to green. Even switching to a console via "ctrl-alt-F1" does not change the screen-output. Upon restarting the X-Server via "ctrl-alt-bkspc", the login sound is heard but still the screen does not display correctly again. I'm using intrepid with the latest updates. My video card is an Intel gma x3100 (gm45). Find attached to the Bug: * xorg.conf * xorg.0.log * back-trace acquired via ssh to the machine
Created attachment 18359 [details] The corresponding xorg.log
Created attachment 18360 [details] backtrace acquired by connecting via ssh
Created attachment 18362 [details] backtrace after continuing
x3100 is GM965 not GM45.
I'd like to know a single action to produce on your side. What's your command for mplayer? which xv port do you use?
(In reply to comment #5) > I'd like to know a single action to produce on your side. What's your command > for mplayer? which xv port do you use? > Hello. I started mplayer with no additional arguments. Just mplayer my_video.avi. I guess I'm using xv port 65 since the command xvinfo returns: $ xvinfo | grep port number of ports: 1 port base: 65 operations supported: PutImage supported visuals:
It looks only overlay video is enabled in ubuntu on 965G. To be sure to use xv, could you test with "mplayer -vo xv moviefile"?
(In reply to comment #7) > It looks only overlay video is enabled in ubuntu on 965G. > > To be sure to use xv, could you test with "mplayer -vo xv moviefile"? > It's the same. After trying a few times X gets corrupted and I have to restart.
Created attachment 18544 [details] A xorg.0.log after the crash happened (reported by another user who has this problem)
Excerpt from the log after crash: (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (This goes on and on and on)
Any progress on this issue? I had to downgrade my system because it was unusable. But if there's code which needs testing I will gladly upgrade again.
Jesse, it looks dsparb should care for overlay plane too, any idea?
Created attachment 18627 [details] [review] Leave Plane C fifo as default We should leave fifo ram for plane C (overlay). This one makes overlay work again on my 965GM.
Created attachment 18631 [details] [review] updated patch Updated patch to check overlay plane usage.
FWIW, the ubuntu package no longer forces overlay video as of 2.4.1-1ubuntu1.
Could you use xv overlay port to test with my patch?
I tried this update patch to see if it fixed the complete Blue Screen i'm seeing when trying to use the XV overlay on a 965gm and it did not fix it. using latest GIT with this patch resulted in no change (though my xserver does not crash as reported in this bug... just a blue screen). thanks, m
Please, don't make bug title empty. Manu, what's your driver version? The bug only affects people using 2.4.x driver, and do you use dual-monitor? overlay can be only working in one pipe, so in clone mode, only one monitor can get display and the other is blue. Overlay port has xv attribute to change the pipe number in this case.
(In reply to comment #18) > The bug only affects people using 2.4.x driver Zhenyu, if this only impacts 2.4 driver, we should remove it blocking #16926 (2.5).
I can confirm that this still occurs with the patch applied. Tested using MPlayer with "-vo xv:adaptor=1" where Xv Adaptor 1 is the overlay. Version of driver used was 2.4.2.
Actually I never meat overlay video crashing xserver issue on T61 here, only video content corrupt I've seen with overlay port. And it looks only 965-ish is affected by this. Could you try to assign always TRUE to DSPARB_HWCONTROL() in src/common.h? like #define DSPARB_HWCONTROL(pI810) (TRUE) to see if your display arb setting caused this.
Created attachment 19395 [details] [review] 965GM patch From my testing this problem seems only happen on 965GM. So update with this patch. Sean, what's your type of machine? Does this one work for you?
I am using a notebook with a GMA X3100 on a 965GM chipset. Will test the patch later.
The crash appears to be fixed with the patch. At least, creating and destroying overlays non-stop for an hour has not caused any crashes.
I don not see that overlay video crashing xserver issue on our T61.
Sean, could you try current git master without my patch? It looks I can't produce this too on T61 now.
I tagged onto the ubuntu bug as it had similar symptoms, however the hardware affected is a ThinkPad R51 with an 855GM(E?). If it would help, I've got logs and backtraces of the lockup. Symptoms for the laptop are any video played in Kubuntu 8.10 with XV plays fine for a few seconds then screen blacks out as well as consoles. X and consoles (usually) still respond, but video is not restored until reboot and X can't restart. Logs show DSPARB warnings, under runs, and ring errors. FWIW, I tried the patch against the ubuntu driver (2.4.1-1ubuntu10), but it didn't resolve the problem. Feel free to kick me to a new bug if that's better.
I have the exact same issue (underrun on pipe B!, followed by a crash of the X server, rendering the display unuseable until reboot, but leaving the system more or less running) on a Dell X.300, 855GM, under kubuntu 8.10. Upgrading to 2.5.1 from debian unstable did not help. Some experiments with xorg.conf with "ForceEnablePipeA" and different virtual sizes didn't make a difference either. Disabling the KDE "Detecting RANDR (monitor) changes" stopped the crashes from occuring. Seems this bug is somehow related to whatever said service is doing in the background.
I can still confirm this on xf86-video-intel 2.6.1 (or whatever the latest is). Using a Thinkpad T61 with GMA3100.
Blargh, I meant 2.5.1.
Can we test this against 2.6 rc1? I can't produce it on my T61 now.
(In reply to comment #29) > I can still confirm this on xf86-video-intel 2.6.1 (or whatever the latest is). > Using a Thinkpad T61 with GMA3100. > Sean, can you reproduce this bug easily or even every time playing video?
No, bug happens randomly. In 2.5.1, it manifests as the overlay starting out as a blue window that causes X to stop responding if I try to kill it.
I have the same bug (blue screen) when I use overlay xv with VLC with todays driver from git and kernel 2.6.28 and this bug seems to happen ofter but I don't see anything in the logs. I've tried the patch from comment #22 but it didn't fix the bug. (I've only restared X) My system is Thinkpad T61 with Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
(In reply to comment #33) > No, bug happens randomly. In 2.5.1, it manifests as the overlay starting out as > a blue window that causes X to stop responding if I try to kill it. > Sean, are you able to reproduce this on 2.6.1? Zhenyu said he couldn't reproduce this bug anymore. If you still can, we need to compare the SW environment you and zhenyu use. would you please provide: 1) your T61 model, usually on the back of your laptop, to make sure we are using the same T61. 2) are you using a pristine Linux distribution? we will try to grab that distribution and reproduce on it 3) if you are using upstream driver, would you please tell us the git id you used to build the driver components? ( Xserver, Xf86-video-intel, Mesa, etc ) Roman Jarosz, you are also welcomed to provide response for the above steps..thanks.
I still can reproduce this with latest driver, every time I start new video in vlc the screen brakes for approximately half of second and then it restore itself. But sometimes (somewhere between 30 video starts/stops) the screen brakes but instead of restoring back the whole screen turns green or white and the X server is stuck. When I attached the gdb to X server once I got this backtrace #0 0x00007f8397b664e3 in writev () from /lib/libc.so.6 #1 0x00000000004f3b7c in ?? () #2 0x00000000004ef321 in FlushClient () #3 0x00000000004efa38 in WriteToClient () #4 0x0000000000449c1c in ProcGetImage () #5 0x000000000044ba24 in Dispatch () #6 0x00000000004319fd in main () and two times (I forgot to save it, sorry) that X server is waiting for something. libdrm: 854bd8f2cae8389d1152993a1d751687632df323 branch 'master' of git://anongit.freedesktop.org/git/mesa/drm xf86-video-intel: 66bc44e8f9a0505c0b11b8042243ca74079da85f branch 'master' of git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel sys-kernel/vanilla-sources-2.6.28.2 + http://intellinuxgraphics.org/download/2008Q4-rc4/2008q4-kernel-against-2.6.28.patch x11-base/xorg-server-1.5.99.902 sys-devel/gcc-4.3.3 sys-libs/glibc-2.9_p20081201-r1 T61 model: 6466-9MG SN: L3-E3934 The problem is that there's nothing in Xorg.log/dmesg when it is stuck.
Created attachment 22435 [details] Xorg log when X was stuck Here's xorg log when it happen. Oh and mesa is media-libs/mesa-7.3
As a result of this bug, I have returned to Microsoft Windows and can not provide further feedback. If you can not reproduce this bug, go ahead and close it. I was using Gentoo Linux's in-tree version with the CFLAGS "-O2 -fomit-frame-pointer -ftree-vectorize -ftree-loop-linear -pipe". I can provide my T61 model number as well, but I do not have access to it right now.
Hi all, i got the same problem on my asus eee box using: Linux-2.6.28 mesa-7.3 xorg-server-1.5.3-r2 xf86-video-intel-2.6.1 The result of this bug is the same here: black,grey, white display or it even shut off. Everything still works, i can ssh to the machine and there are no errors in xorg-log, dmesg or anything else. Playing videos (xv) or watching tv via my usb-tv-card(uses xv too i think) increases the rate of hangs but they are totally random at all, sometimes it works for hours and sometimes i've to reboot every 15 minutes. I've another system with a intel 945 - without ever having any problem. I'm willing to do (any) tests cos currently my system is kinda unuseable :-( . The dmesg, xorg.conf and lspci output is attached. Thanks for any helpfull comments.
Created attachment 23041 [details] lcpci of Asus eee Box
Created attachment 23042 [details] weird dmesg memory complains on Asus eeeBox
(In reply to comment #40) > Created an attachment (id=23041) [details] > lcpci of Asus eee Box > yours is a different issue, please try suggestions in bug# 19304, bug# 18651 instead.
Hi, Roman I rebuild the X environment based on the branch mentioned in comment #36 and then play the media file for about an hour. But unfortunately this bug can't be reproduced on the T61. >The model name of T61 is 646557U. Will you please try to use the VESA driver instead of intel graphics driver and see whether the issue still can reproduced on your box? thanks.
Hi ykzhao, I can't test it with vesa because vesa doesn't have video overlay. You said that you can't reproduce, did you use vlc with xv overlay video output (with exa or uxa)? If you tell me how to get you more relevant info I would gladly provide it. I can compile kernel/xserver/mesa/intel with any patches/settings you want.
Forgot to tell that since couple of days the overlay video window is solid green and I can still freeze the whole xserver with xf86-video-intel from git and linux/kernel/git/anholt/drm-intel.git from for-airlied
Hi, Roman I do the test by using VLC with xv video overlay output. But it still can't be reproduced. Can this issue be reproduced on your box if the video overlay output is not used?
(In reply to comment #46) > Can this issue be reproduced on your box if the video overlay output is not used? No, textured video works fine (only tearing bugs me). This is probably not related but UXA sometimes freeze here (bug 19911). EXA is ok, even with opengl windows manager.
Adjusting severity: crashes & hangs should be marked critical.
I fixed some small races in the overlay code recently, could you re-test? commit af6892f2b873dd508994d8bbf3d67e719b535e35 Author: Eric Anholt <eric@anholt.net> Date: Mon Apr 20 16:07:05 2009 -0700 Replace i830WaitSync with just I830Sync(), as nearly all callers had it wrong
No response over 6 weeks, so I assume Eric's fix works. Please reopen if you can still reproduce this with 2.8.x.
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.