After upgrading from xorg 6.8.0 (Gentoo stable xorg-x11-6.8.0-r4) to 6.8.2 (Gentoo stable xorg-x11-6.8.2-r1) I started getting this error when using applications with XVideo output (ie. all my video players): BadAlloc (insufficient resources for operation) serial 160 error_code 11 request_code 140 minor_code 19 This happens on mplayer used with -vo xv, (tried both mplayer stable and current ~x86) and totem. Xine shows only a blue screen and does not play the video so I presume a similar problem shows up. I do not get the problem in mplayer with -vo x11, so I presume XVideo is broken in this release. This happens only when I play large clips. In particular the ones that I tried were larger than my LCD video display (1024x768), all the small clips I have around *seem* to play fine. My video card is: 0000:01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility M3 AGP 2x (rev 02) I'm using the stock xorg r128 driver with DRI enabled. A snippet of some sample output from mplayer: VO: [xv] 1152x864 => 1152x864 Planar YV12 aspect: Warning: no suitable new res found! aspect: Warning: no suitable new res found! aspect: Warning: no suitable new res found! X11 error: BadAlloc (insufficient resources for operation) I'm attaching some relevant files and configs.
Created attachment 2149 [details] My xorg.conf
Created attachment 2150 [details] Output from xvinfo
Created attachment 2151 [details] My current Xorg.0.log
Created attachment 2152 [details] Out from emerge --info on my Gentoo system. This file might include some useful information for anybody reviewing this bug.
Update. After reverting back to 6.8.0 (trying to get rid of the bug) it turned out I'm still experiencing it. I just never tried playing very large video clips before moving to 6.8.2 it seems. Anyway, this bug still bugs me and is valid, so please take a look at this sometime.
This bug appears similar to one at: https://bugs.freedesktop.org/show_bug.cgi?id=474 The above bug has been repoened. I am experiencing problems with XV unable to play high definition 1920x1080 video streams under mythtv. Lower resolution video streams play perfectly. When displaying a HD stream, mythtv repeatedly reports: X Error: BadAlloc (insufficient resources for operation) 11 Major opcode: 142 Minor opcode: 19 Resource id: 0x0 I am running linux-2.6.12-gentoo-r1, xorg 6.8.2, ATI binary Radeon X800 XL 256MB fglrx version 8.14.13, on a Pentium 4 2.4 GHz system.
I have the same problem on a 256M ram box with xorg 7.0 and i815 onboard video. I had tha same problem on home box (NVidia card there) with older X, but I upgraded ram to 256M+512M and it stopped to happen. On to bug report. Trying to run "mplayer -v valles3d_hd.wmv" says: ... Starting playback... lavc_audio: error avg. framerate: 4 fps *** [vo] Allocating mp_image_t, 1280x720x12bpp YUV planar, 1382400 bytes get_path('subfont.ttf') -> '/home/vda/.mplayer/subfont.ttf' New_Face failed. Maybe the font path is wrong. Please supply the text font file (~/.mplayer/subfont.ttf). subtitle font: load_sub_face failed. [xv] dx: 0 dy: 0 dw: 1273 dh: 764 A: 4,0 V: 3,0 A-V: 0,974 ct: 0,000 1/ 1 ??% ??% ??,?% 0 0 Type: 0, display: 873f910, resourceid: 1a00001, serial: 5c Error code: b, request code: 8c, minor code: 13 MPlayer interrupted by signal 6 in module: vo_check_events ... mplayer -v -vo x11, which does not use XVideo, works fine. diff -u mplayer_xvideo.log mplayer_x11.log: Decoder is capable of YUV output (flags 0x1b) VDec: vo config request - 1280 x 720 (preferred csp: Packed YUY2) Trying filter chain: vo -VDec: using Planar YV12 as output csp (no 0) +VDec: using BGRA as output csp (no 3) Movie-Aspect is undefined - no prescaling applied. -VO Config (1280x720->1280x720,flags=0,'MPlayer',0x32315659) -VO: [xv] 1280x720 => 1280x720 Planar YV12 -VO: Description: X11/Xv -VO: Author: Gerd Knorr <kraxel@goldbach.in-berlin.de> and others -Xvideo image format: 0x35315652 (RV15) packed -Xvideo image format: 0x36315652 (RV16) packed -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 57 for hw scaling -[xv] dx: 0 dy: 0 dw: 1280 dh: 768 +VO Config (1280x720->1280x720,flags=0,'MPlayer',0x42475220) +VO: [x11] 1280x720 => 1280x720 BGRA +VO: Description: X11 ( XImage/Shm ) +VO: Author: Aaron Holtzman <aholtzma@ess.engr.uvic.ca> +Sharing memory. +SwScaler: using unscaled BGRA -> BGRA special converter INFO: Win32/DMO video codec init OK. Selected video codec: [wmv9dmo] vfm:dmo (Windows Media Video 9 DMO) ========================================================================== @@ -145,25 +139,17 @@ lavc_audio: error avg. framerate: 4 fps -*** [vo] Allocating mp_image_t, 1280x720x12bpp YUV planar, 1382400 bytes +*** [vo] Allocating mp_image_t, 1280x720x32bpp BGR packed, 3686400 bytes get_path('subfont.ttf') -> '/home/vda/.mplayer/subfont.ttf' New_Face failed. Maybe the font path is wrong. Please supply the text font file (~/.mplayer/subfont.ttf). subtitle font: load_sub_face failed. -[xv] dx: 0 dy: 0 dw: 1273 dh: 764 -X11 error: BadAlloc (insufficient resources for operation) -Type: 0, display: 873f910, resourceid: 1a00001, serial: 5c -Error code: b, request code: 8c, minor code: 13 - -MPlayer interrupted by signal 6 in module: vo_check_events -MPlayer crashed. This shouldn't happen. valles3d_hd.wmv is available at: http://video.mars.asu.edu:81/valles3d_hd.wmv http://128.100.103.4/mirror/mars/valles3d_hd.wmv (you do not need to download all of it, just a few megs will do).
This looks like a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=2445 but I'm confused by the last comment from Matthew Tippett, saying it should be fixed. I also get the same problem with an intel 855 gm card and xorg 7.1 trying to play Elephants_Dream_HD.avi available here : http://orange.blender.org/download mplayer crash with the BadAlloc error : ... VO: [xv] 1920x1080 => 1920x1080 Planar YV12 ... X11 error: BadAlloc (insufficient resources for operation) Xine crash with only : xiTK received SIGSEGV signal, RIP. mplayer allow to scale down the resolution, and at 800x600 the movie plays fine: $ mplayer -vf scale=800:600 Elephants_Dream_HD.avi ... VO: [xv] 800x600 => 1066x600 Planar YV12 ... The limit seems to be somewhere between 800x600 and 1024x768, which is still quite far from 1920x1080. I don't know if this information is relevant and what it exactly means : $ xvinfo |grep max maximum XvImage size: 1920 x 1080 The i810 driver can benefit from the CacheLines option, by adding this in xorg.conf : Option "CacheLines" "1024" With the following, I can still not play the movie at its native 1920x1080 resolution, but with mplayer scaling it down at 1024x768 , it works. Apparently, the default for CacheLines is 512, and it can go up to 1040 with an intel 855 GM chipset.
Sorry, the maximum CacheLines is in fact 1280. What I find a bit strange however is that increasing VideoRam (default is 65536) doesn't seem to help at all. I believe this chipset support up to 128MB, and that's also what xorg log seems to tell when I try to set VideoRam to a higher value: (WW) I810(0): VideoRAM reduced to 196608 kByte (page aligned - was 200000) (WW) I810(0): VideoRam reduced to 131072 kByte (limited to aperture size) (II) I810(0): Will attempt to tell the BIOS that there is 12288 kB VideoRAM (II) I810(0): BIOS now sees 12288 kB VideoRAM (--) I810(0): Pre-allocated VideoRAM: 8060 kByte (**) I810(0): VideoRAM: 131072 kByte (--) I810(0): Maximum frambuffer space: 130904 kByte I tried with mplayer again (with VideoRam to either 65536 or 131072) to see what was the highest 16:9 resolution that didn't crash. With the default CacheLines (512), it's 1072x603 With CacheLines set to the max (1280), it's 1728x972
This time, I tried to set the lowest VideoRam, using power of two. If VideoRam is set to 8192, i810 fails to allocate framebuffer, and xorg can't start. With VideoRam 16384, it works fine, and I still get the same result with mplayer than with VideoRam 65536 or 131072. So VideoRam seems to have 0 influence on this issue, is this expected ? CacheLines however has a direct influence on it.
I see this on my notebook as well trying to play HD (1280x720) video. xorg 7.1.1 w/ intel 1.7.2 driver Intel 945GM w/ 2 GB of RAM (II) I810(0): detected 7932 kB stolen memory. (II) I810(0): Kernel reported 488960 total, 1 used (II) I810(0): I830CheckAvailableMemory: 1955836 kB available (II) I810(0): Monitoring connected displays enabled (II) I810(0): Will attempt to tell the BIOS that there is 12288 kB VideoRAM (II) I810(0): BIOS now sees 12288 kB VideoRAM (--) I810(0): Pre-allocated VideoRAM: 7932 kByte (==) I810(0): VideoRAM: 65536 kByte The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 499 error_code 11 request_code 141 minor_code 19) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.)
The original reporter said this was on an ATI chip, but for those running with Intel chips you need to use the option... Option "LinearAlloc" "8192" to give more memory to the allocator to allow for HDTV playback.
Oops. I totally missed that in the man page :embarrassed: I'm curious, is there a reason the driver cannot allocate this automatically somehow under various conditions? Thank you for your help!
Normally XAA gets a small portion of memory for offscreen allocation, but due to rasterizer limits it only gets a smaller portion of memory and it just so happens that the Xv allocator uses the same memory manager and suffers from the same restrictions even though the hardware Xv setup doesn't have the limits. So, we end up allowing the user to add extra memory resources to the allocator specifically for Xv. We can define some conditions to allocate more Xv memory, but it just hasn't been done and so it's left to the user to allocate it.
I'm seeing this as well under Ubuntu 6.10 (xorg 7.1). Sporadically, when I try to launch the vlc media player, I see this error message: X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 141 (XVideo) Minor opcode of failed request: 19 () Serial number of failed request: 82 Current serial number in output stream: 83 Rebooting X is the only solution. My video card is: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller I am using the standard i810 xorg driver.
Removing me from this bug as the original report is ATI related - not Intel.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Probably a duplicate of bug #474. To original reporter only: Please test with a more recent version of Xserver and reopen if it persists. Better yet, open another report as this is swamped by fixed issues on other cards.
The problem PERSISTS with the latest xorg and i810 driver. I had to use the Cachelines trick to make my HD video to work with my Intel 945 card. Otherwise, totem,mplayer,vlc/etc they all crash because Xv can't cope with the large video files. To test it, just download an HD trailer with an Xv-capable media player. Please note that for SOME i8xx cards, the Cachelines trick does not work at all, and for those users, they can only hope for a fixed driver.
Confirming with xorg-x11-server-Xorg-1.3.0.0-5.fc7 and Section "Device" Identifier "Videocard0" Driver "i810" Option "VideoRam" "65536" Option "LinearAlloc" "6144" EndSection I get this even with small videos (320x200) if played multiple times with mplayer, which suggest a video memory leak.
From bug 10912: " After talking to Eric, he mentioned that the problem is because of the use of XAA. And although he doesn't directly mention what the work-around is, he repeated it to me during our talk. Add to the device section: Option "AccelMethod" "EXA" It doesn't exactly work well on my machine (performance-wise), but it does play instead of crashing. "
As Hadess says, yes, it works and doesn't crash, but performance is *awful*, and it appears to slow down all other windowing operations in Compiz, too. For example, changing faces on the cube takes almost a full second if I have any windows up on the new cube face. Without EXA, it's liquid-smooth, no drag or delay.
Closing, EXA acceleration should be a lot better with recent xserver (>1.6.1) and recent x86-video-ati. Reopen if you have same issue with such recent software.
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.