On my laptop the X server started to crash with the 2.6.31+ kernel when I access the xvideo overlay after the resume, provided that the xvideo overlay has also been previously accessed before the suspend-to-ram. Without accessing the xv overlay (e.g. by mplayer), I can suspend and resume the system freely, but as soon as I use the overlay, accessing it again after the next suspend/resume cycle crashes the X server. It does not matter whether I run a new mplayer, or keep the existing one running during the suspend/resume cycle. The X server then keeps crashing (I am attaching the Xorg.0 log). Apart from that, the rest of the system is working (nothing special in dmesg(8), I can log in remotely, etc.). With 2.6.30, the xvideo users can withstand the suspend/resume cycle without a problem. The hardware is ASUS F3E with the following chipset: 00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03) The software is: Fedora 11, x86_64, 2.6.31 or 2.6.32-rc3 kernel (2.6.30 works) xorg-x11-server-Xorg-1.6.4-0.1.fc11.x86_64 xorg-x11-drv-intel-2.7.0-7.fc11.x86_64 More info available on request.
Created attachment 30213 [details] Xorg.0.log
just curious why you want to use video overlay instead of the default textured video for playing media? (or maybe you actually didn't force overlay?) I didn't expect f11 uses a new server while a pretty old intel driver (2.7). Are you able to try a newer driver (2.9)?
Isee there's a similar bug (#24979) that Daniel's looking at. Maybe they have the same root cause or this one is gone now?
> --- Comment #3 from Jesse Barnes <jbarnes@virtuousgeek.org> 2009-11-20 13:14:46 PST --- > Isee there's a similar bug (#24979) that Daniel's looking at. Maybe they have > the same root cause or this one is gone now? Maybe. Symptoms match exactly, as far as I can see, but this seems to be ums whereas the other bug is with kms. Funny that the ums case seems to break due to a kernel change. Like with the other i965 overlay promblems I suspect a cash flush/synchronization problem creating havoc to the overlay command stream. At least that's the most likely explanation in my opinion. With ums we should be able to check this by defining OVERLAY_DEBUG and VIDEO_DEBUG in src/i830_video.c -Daniel
Re: comment #2: I did not force the overlay or any other -vo driver in mplayer. mplayer says "vo: [xv]" by default. In the meantime, I have upgraded to Fedora 12 (xorg-x11-drv-intel-2.9.1-1.fc12.x86_64, 2.6.31-based Fedora kernel), and it seems the intel driver works even after suspend/resume (including mplayer) for me. However, I had no luck with vanilla kernel: with CONFIG_DRM_I830 (i.e. probably without KMS) the intel driver works and is fast, but as soon as I try to start mplayer (even without suspend) the X server crashes and is restarted by gdm. With CONFIG_DRM_I915 and KMS the X server starts, but it is probably not accelerated, because it takes about 5 minutes to display the gdm greeter window, while the X server takes 100% of CPU time, and the mouse response is very sloppy (maybe 2 or 3 redraws of the cursor per second only). This is on the latest 2.6.31.6 and 2.6.32-rc8. Maybe I have forgotten to enable some other important kernel option, or Fedora has some distro-specific patches which are not yet upstream. Should I open a new bug for this?
I've just resolved #24979 (resume hang with kms overlay) and that one was a bug in my kernel overlay code. So this looks like a totally different issue. -Daniel
Yeah, those other issues sound like separate bugs. You should always use the i915 driver, and make sure you have a recent 2D driver (ideally 2.10) or things will be really slow.
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.