Bug 126307
Summary: | X11 error: BadAlloc (insufficient resources for operation) when trying to play video clips with other apps loaded | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Motor <gmotor> | ||||
Component: | xorg-x11 | Assignee: | X/OpenGL Maintenance List <xgl-maint> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | |||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 2 | CC: | ccradu, great.snoopy, jshin, mharris | ||||
Target Milestone: | --- | Keywords: | Triaged | ||||
Target Release: | --- | ||||||
Hardware: | athlon | ||||||
OS: | Linux | ||||||
URL: | http://freedesktop.org/bugzilla/show_bug.cgi?id=474 | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2005-02-01 09:59:27 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Created attachment 101246 [details]
My Xorg config file
X11 error: BadAlloc (insufficient resources for operation) Type: 0, display: 9182cd0, resourceid: 2200001, serial: 56 Error code: b, request code: 8d, minor code: 13 This an application error. X told the mplayer code that at it was not at this time able to fulfill the request (almost certainly for the big offscreen video buffers for the video overlay). Mplayer should have fallen back to Xshm or handled the event nicely. You should report this to mplayer instead. *** Bug 80535 has been marked as a duplicate of this bug. *** Hi, I've ran into the same problem while fixing some bugs in GStreamer. So I took a day out to dig a bit deeper. I'm not convinced it's only an application error. First of all, I don't see any way how the application can fall back gracefully to some other method that allows it to display video. If you happen to know of one, please let me know. Second, the root of the problem is the fact that both X overlays and mapped pixmaps in the X server are stored in the video card's memory. Keith Packard tells me: <keithp> thomasvs: oh, that's just broken video drivers. <keithp> thomasvs: lame allocators that can't migrate pixmaps from video memory to system memory to make space for the Xv buffer. ie, when an application draws to an X overlay, the driver *should* move away some mapped pixmaps from the video card to system memory. Unfortunately, it seems that not a lot of X drivers do this. Now, the browser seems to be the one application that eats the most X memory - easily more than 10 MB with a bunch of tabs open. So the problem can be verified by opening up a lot of tabs, until a video application is unable to display using Xv. Then start closing tabs until the X memory usage is sufficiently low enough so that an X overlay can be drawn to again. Keith says that the correct place to fix this is in the X driver, migrating pixmap data off of the card. The browser should not try to fix by unloading pixmap data itself, and the video application cannot display video due to the memory depletion. Can someone think of a good way out of this ? This IS a bug, and IS a bug in xorg. Saying that "mplayer should fall back to shm" is plain stupid, as shm does not the same scaling capabilities as xv. It's absurd to be impossible to do video fullscreen because some apps are eating some video memory. Here is the link to prove that this IS a fscking BUG. http://freedesktop.org/bugzilla/show_bug.cgi?id=474 Thanks Great Snoopy, we'll track this problem upstream now. Setting status to UPSTREAM. You are welcome :) And an additional note : The normal behaviour of a modern video card (helped by the driver, of course) is to use portions of standard video memory when the videocard's memory is exhausted. Using means using that memory directly or moving less used chunks of video memory back into the main memory. This is why the AGP was created for, but it seems that the xorg is not using it right. It also seems that this problem has its origins in late pre 4.4 XFree86 sources and has been merged in xorg. There are many people affected by this problem, and is not dependent on video driver. People with more video memory on their cards are less affected, but the problem still exist on their setups, too. I also could note that the suggested temporary workaround, Option "XaaNoOffscreenPixmaps" in device section works for many people,me included. G-S You are welcome :) And an additional note : The normal behaviour of a modern video card (helped by the driver, of course) is to use portions of standard video memory when the videocard's memory is exhausted. Using means using that memory directly or moving less used chunks of video memory back into the main memory. This is why the AGP was created for, but it seems that the xorg is not using it right. It also seems that this problem has its origins in late pre 4.4 XFree86 sources and has been merged in xorg. There are many people affected by this problem, and is not dependent on video driver. People with more video memory on their cards are less affected, but the problem still exist on their setups, too. I also could note that the suggested temporary workaround, Option "XaaNoOffscreenPixmaps" in device section works for many people,me included. G-S This problem just hit my wife's computer, a brand new Dell Dimension 2400, running the i810 driver. FC2 is of no use to her now, so we'll have to go with something else. Where can I monitor the status of this issue upstream? Please provide a link. Scratch that. I just patched her system with xorg-x11-6.7.0-5 and the problem is now gone. >Where can I monitor the status of this issue upstream? Please provide >a link. See comment #5 >Scratch that. I just patched her system with xorg-x11-6.7.0-5 and
>the problem is now gone.
I have xorg-x11.6.7.0-5 installed and the problem still occurs. BTW,
freedesktop link posted by Mike Harris has a workaround for the
problem (Option "XaaNoOffscreenPixmaps").
To the best of my knowledge, the problem described herein, and in the currently open upstream bug report that we are tracking, is not fixed in any Xorg release currently, nor in CVS head. Unfortunately, the problem is not marked as a release blocker in upstream bugzillz either, and so it probably will not be addressed in the 6.8.0 release unless someone having the problem can convince the X.Org developers it is a critical issue that should block the release. Once it is fixed in upstream CVS however, we will review the fixes that were commited to CVS, and if they are non-risky to apply to 6.7.0, we may consider backporting the upstream fixes to a future FC2 update. For the time being, it is best if everyone carbon copies themselves on the upstream bug report, and follows up with upstream, as that is where the issue is being tracked, and freedesktop.org developers are probably not watching this bug in Red Hat bugzilla, so they'll miss any valuable information provided here. For reference, the upstream bug URL is: http://freedesktop.org/bugzilla/show_bug.cgi?id=474 The upstream bug has been closed on this now, is the fix in FC3-test? Thanks for the info on the upstream bug. Reopening for investigation for consideration in future xorg-x11 builds. With X.org 6.8.1 and 'nv' driver (my computer is Dell D800 with Nvidia card), I still have the problem. I'm now trying 'Option "XaaNoOffscreenPixmaps"'. Upstream claims this issue is fixed in 6.8.1 in the bug: http://freedesktop.org/bugzilla/show_bug.cgi?id=474 so I am closing this as being fixed in FC3 "CURRENTRELEASE". If anyone still experiences this problem at all, please open a brand new bug report in X.Org bugzilla, attaching all relevant details to the new report. Once your new bug report is filed in X.Org bugzilla, it will eventually get reviewed by an X developer. If they determine there is a real bug present, and someone fixes it, we will review the fix for consideration in future Fedora Core updates if someone pastes the new bug URL into a Red Hat bug report. Setting status to "CURRENTRELEASE" |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 Galeon/1.3.14 Description of problem: Open a few galeon tabs with web sites loaded, or XMMS (or presumably anything which uses a lot of X windows) and then try to play a video clip using mplayer or xine causes problems: xine won't display video, and mplayer bombs out in a more descriptive way (copy included below). Closing galeon and XMMS allows the video to play with no other changes to the setup. I've attached my xorg.conf file -- it was generated by system-config-display, with a few font dirs added. Version-Release number of selected component (if applicable): xorg-x11-6.7.0-2 How reproducible: Always Steps to Reproduce: 1. Open a few galeon windows, with plenty of tabs loaded with websites+XMMS+anything else. Doesn't work unless plent of tabs are populated with websites -- and sometimes needs XMMS running too. 2. run command: mplayer videoclip.avi Actual Results: >mplayer -v videoclip.avi Starting playback... [ffmpeg] aspect_ratio: 1.333333 VDec: vo config request - 320 x 240 (preferred csp: Planar YV12) Trying filter chain: vo VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.33:1 - prescaling to correct movie aspect. VO Config (320x240->320x240,flags=0,'MPlayer',0x32315659) VO: [xv] 320x240 => 320x240 Planar YV12 VO: Description: X11/Xv VO: Author: Gerd Knorr <kraxel.de> and others Xvideo image format: 0x32595559 (YUY2) packed Xvideo image format: 0x32315659 (YV12) planar Xvideo image format: 0x30323449 (I420) planar Xvideo image format: 0x59565955 (UYVY) packed using Xvideo port 69 for hw scaling [xv] dx: 0 dy: 0 dw: 320 dh: 240 *** [vo] Allocating (slices) mp_image_t, 320x240x12bpp YUV planar, 115200 bytes [xv] dx: 0 dy: 0 dw: 320 dh: 240 *** [vo] Allocating (slices) mp_image_t, 320x240x12bpp YUV planar, 115200 bytes X11 error: BadAlloc (insufficient resources for operation) Type: 0, display: 9182cd0, resourceid: 2200001, serial: 56 Error code: b, request code: 8d, minor code: 13 MPlayer interrupted by signal 6 in module: flip_page - MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and won't help unless you provide this information when reporting a possible bug. Uninit audio filters... [libaf] Removing filter dummy uninit audio: faad FAAD: Closing decoder! uninit video: ffmpeg DEMUXER: freeing demuxer at 0x9133038 DEMUXER: freeing sh_audio at 0x913f968 DEMUXER: freeing sh_video at 0x91600c0 Xlib: unexpected async reply (sequence 0x59)! vo: uninit ... Expected Results: Should have played Additional info: System specs: Matrox G550 (32Mb RAM) AMD Athlon XP2000+ Gigabyte Triton motherboard (VIA chipset) 512Mb RAM