[i945gm] all video players crash with BadAlloc error (no Compiz, Xv) if Virtual width > 2048.

[Peter Bhat Harkins]

Binary package hint: xserver-xorg-video-intel

xine, mplayer, or totem all crash when attempting to play any video file with an error like this one from xine:
This is xine (X11 gui) - a free video player v0.99.6cvs.
(c) 2000-2007 The xine Team.
X Error of failed request: BadAlloc (insufficient resources for operation)
  Major opcode of failed request: 132 (XVideo)
  Minor opcode of failed request: 19 ()
  Serial number of failed request: 4731
  Current serial number in output stream: 4732

This worked in Intrepid and does not work since updating to the Jaunty beta this morning. I noticed it removing the xserver-xorg-video-i810 package and I can see other similar bugs saying that this has been deprecated in favor of xserver-xorg-video-intel.

mplayer -vo x11 file.avi works, so it seems very likely this is an xvideo problem.

One oddity: at first, 'mplayer file.avi' crashed immediately. After trying to run it and other video players a few times, now it opens a black window, plays the audio, and spams "X11 error: BadAlloc (insufficient resources for operation)" to console. I didn't change any settings (cross my heart), I was just hitting up and rerunning the last couple attempts to show someone in the room.

ProblemType: Bug
Architecture: i386, x86_64
DistroRelease: Ubuntu 9.04
Package: xserver-xorg-video-intel 2:2.6.3-0ubuntu9
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8
ProcVersion: Linux version 2.6.28-11-generic (buildd@rothera) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #41-Ubuntu SMP Wed Apr 8 04:38:53 UTC 2009
SourcePackage: xserver-xorg-video-intel
Uname: Linux 2.6.28-11-generic i686

[lspci]
00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub [8086:27a0] (rev 03)
     Subsystem: Intel Corporation Device [8086:7270]
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03)
     Subsystem: Intel Corporation Device [8086:7270]

[Utter28 (utter28)]

I would just like to say that I am concerned about this as well. I have tried stacking my displays vertically but it feels unnatural to the point of being unusable. I don't know much about the hardware or xorg limitations at play here but why is the maximum size constrainted to 2048 in any direction? why not 4194304 total pixels?

[Michael Fu (michael-fu-intel)]

the work in in progress though slowly...

[Gordon Jin (gordon-jin)]

*** Bug 11939 has been marked as a duplicate of this bug. ***

[Eric Anholt (eric-anholt)]

It's a real hardware limitation, which was fixed in the 965 and later chipsets. With a bunch of software we can work around it at a significant performance cost, and ajax has been working on that.

[Gordon Jin (gordon-jin)]

ajax is working on Shatter for this: http://linux.conf.au/programme/schedule/view_talk/76?day=friday

[Simos Xenitellis  (simosx)]

Regarding the 965 chipsets, 3D desktop works when the size is bigger than 2048x2048, with a caveat. I believe many users will be stuck with this and think that the 965 does not support hardware acceleration when > 2048x2048.

1. When the desktop size is bigger than 2048x2048 and you run

$ compiz --replace &
Detected PCI ID for VGA:
Checking for texture_from_pixmap: not present.
Trying again with indirect rendering:
Checking for texture_from_pixmap: present.
Checking for non power of two support: present.
Checking for Composite extension: present.
Comparing resolution (2304x800) to maximum 3D texture size (2048): Failed.
aborting and using fallback: /usr/bin/metacity
$ _

Compiz does not start.

2. However, if you reduce the size (using xrandr) to something less than 2048x2048 and try again

$ compiz --replace &
Detected PCI ID for VGA:
Checking for texture_from_pixmap: not present.
Trying again with indirect rendering:
Checking for texture_from_pixmap: present.
Checking for non power of two support: present.
Checking for Composite extension: present.
Comparing resolution (2048x768) to maximum 3D texture size (2048): Passed.
Checking for Software Rasterizer: Not present.
Checking for nVidia: not present.
Checking for FBConfig: present.
Checking for Xgl: not present.
/usr/bin/compiz.real (video) - Warn: No 8 bit GLX pixmap format, disabling YV12 image format
Starting gtk-window-decorator
$ _

Now, while the 3D desktop is activated, you can use xrandr to bring the resolution to the original full size (in my case, 2304x800), and the 3D desktop is still working.

Who should we bother to fix the test 'Comparing resolution (2304x800) to maximum 3D texture size (2048): Failed.' so that it does not fail with the 965?

[perfectom (thomas-klopf)]

This issue I'm having with:
Integrated Graphics Chipset: Intel(R) Mobile Intel® GM45 Express Chipset

Is this considered pre-965? Will this fix apply to all intel chipsets then? I think quite a lot of people are interested in this being fixed, in fact for me and my colleagues I'd say it's the biggest limitation for our desktops. Many beers for whoever can get this one taken care of :). Thanks a lot!

[Gordon Jin (gordon-jin)]

(In reply to comment #7)
> This issue I'm having with:
> Integrated Graphics Chipset: Intel(R) Mobile Intel® GM45 Express Chipset
>
> Is this considered pre-965?

No. GM45 is supposed to work without this limitation. If you have such problem, please file a separate bug.

[Peter Bhat Harkins (pushcx)]

Binary package hint: xserver-xorg-video-intel

xine, mplayer, or totem all crash when attempting to play any video file with an error like this one from xine:
This is xine (X11 gui) - a free video player v0.99.6cvs.
(c) 2000-2007 The xine Team.
X Error of failed request: BadAlloc (insufficient resources for operation)
  Major opcode of failed request: 132 (XVideo)
  Minor opcode of failed request: 19 ()
  Serial number of failed request: 4731
  Current serial number in output stream: 4732

This worked in Intrepid and does not work since updating to the Jaunty beta this morning. I noticed it removing the xserver-xorg-video-i810 package and I can see other similar bugs saying that this has been deprecated in favor of xserver-xorg-video-intel.

mplayer -vo x11 file.avi works, so it seems very likely this is an xvideo problem.

One oddity: at first, 'mplayer file.avi' crashed immediately. After trying to run it and other video players a few times, now it opens a black window, plays the audio, and spams "X11 error: BadAlloc (insufficient resources for operation)" to console. I didn't change any settings (cross my heart), I was just hitting up and rerunning the last couple attempts to show someone in the room.

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: xserver-xorg-video-intel 2:2.6.3-0ubuntu9
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8
ProcVersion: Linux version 2.6.28-11-generic (buildd@rothera) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #41-Ubuntu SMP Wed Apr 8 04:38:53 UTC 2009
SourcePackage: xserver-xorg-video-intel
Uname: Linux 2.6.28-11-generic i686

[Albert Damen (albrt)]

Your xorg.conf contains the line:
Virtual 3200 1200

Therefore DRI cannot be used:
(EE) intel(0): Cannot support DRI with frame buffer width > 2048.

In Intrepid XV could still be used with overlay video. In jaunty XV overlay needs DRI as well.

As a workaround you can use non-XV video, like you already mentioned, or reduce the virtual desktop width to maximum 2048.

[Peter Bhat Harkins (pushcx)]

Thanks for your response, Albert. I hadn't noticed that line in the log file and was unaware of xv's new dependency. I've updated the Wiki page for my model macbook to reflect this: https://help.ubuntu.com/community/MacBook1-1/Jaunty

I can't physically arrange my displays (1280x800 builtin, 1920x1200 external) to put one on top of the other, so I'm out of things to try. It's pretty frustrating to be left with non-xv video, as it's unresizeable and constantly choppy.

Is anyone aware of alternatives besides downgrading to Intrepid?

[Peter Bhat Harkins (pushcx)]

FWIW, this appears related to these freedesktop.org bugs:
http://bugs.freedesktop.org/show_bug.cgi?id=15751
http://bugs.freedesktop.org/show_bug.cgi?id=10479

[cjasonm (aphotographofme)]

hi guys-

from a linux novice, but for what it's worth, i'm having the exactly same problem and here's what i've noticed (it also works as an awkward workaround):

1. install smplayer
2. start the video you'd like to play with smplayer. it should start playing with only the sound.
3. start the same video with vlc or mplayer. it will play with both sound and video.

thanks for your good work!
-c

[robertnull (robert-cluenet)]

This effects the i810 chipset as well from intel. Just a heads up.

[Kim Tyler (ktyler)]

I upgraded from intrepid to jaunty 2 days ago. Since then, totem, vlc and mythtv all fail to display video, eg vlc with message :-

[????????] x11 video output error: X11 request 132.19 failed with error code 11:
 BadAlloc (insufficient resources for operation)
X Error of failed request: BadAlloc (insufficient resources for operation)
  Major opcode of failed request: 132 (XVideo)
  Minor opcode of failed request: 19 ()
  Serial number of failed request: 81
  Current serial number in output stream: 82
---------------------------------------------------
lspci -vv gives : (in part)

00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02)
 Subsystem: Dell Device 0151
 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Interrupt: pin A routed to IRQ 11
 Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M]
 Region 1: Memory at feb80000 (32-bit, non-prefetchable) [size=512K]
 Region 2: I/O ports at ed98 [size=8]
 Capabilities: [d0] Power Management version 1
  Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
  Status: D0 PME-Enable- DSel=0 DScale=0 PME-
 Kernel modules: intelfb
-----------------------------------
dpkg info :-
xserver-xorg-video-intel 2:2.6.3-0ubuntu9
----------------------------------
nothing in xorg.conf, or default values

This was all working in intrepid, dist-upgrade using updatemanager from intrepid to jaunty.

Any idea how to fix it/work around for jjaunty?

[robertnull (robert-cluenet)]

A fix that I've found when googling is specify x11 as the video out. With mplayer you can specify it with the -vo option.

mplayer some_file.avi -your-other-options -vo x11

[Kim Tyler (ktyler)]

Gives poor performance, and difficult to do in mythtv (which is what I use mostly). (and other apps which are frontends for mplayer/xine/et al)
/<begin-rant>
come on guys, how can jaunty be released with screwed drivers like this, when they were working before - or should we go to closed source hardware/drivers like nvidia?
/<end-rant>

[Lucas Rosa Galêgo (lrgalego)]

This bug only happens when I put the subsection

SubSection "Display"
  Virtual 2560 1024
EndSubSection

inside my Screen section in xorg.
The compiz also cant work because of this change.
Using the limit of width every thing works fine.
The -vo option works well to

I'm using the x86-64 arch

[Matthew Holtz (matthew-holtz)]

I also have this problem with an i865 chipset. I can play video with the -vo x11 option in mplayer, but nothing works with xv. I'm anxious for a solution.

[Ronald van Engelen (ronalde)]

This is also the case for all of our HP t5725 thin clients using xserver-xorg-video-radeon!

[Ronald van Engelen (ronalde)]

My last comment seems to be handled in #365843

[Mohammed Sayed (msayed2004)]

Same here but with i810.
http://ubuntuforums.org/showthread.php?p=7161789

[dan (dan-dangray)]

Just to re-open this one for a second - surely this can be worked around.

At the moment i'm running a 1440x900 monitor and a 1024x600 monitor 'stacked'. Could the logic be added to xorg to simply wrap the mouse differently, so that the virtual screen used remains 'vertical' but the mouse jumps up between co-ordinates in reaching the side of a screen, producing the effect of a wide horizontal screen in a vertical virtual desktop?

Does anyone know where the code is that handles this? Would it be an easy add or require major changes to the way Xorg does things?

Sorry - I know this is not a feature request forum, but it does seem a logical workaround.

D.

[robertnull (robert-cluenet)]

I fixed this problem by adding Driver "intel" to the device section of my xorg.conf . Hope this helps other people.

[S. Zeid (s-zeid)]

Is any real progress being made on this bug? It's been open for two years and the only thing I've heard about it is that "ajax is working on Shatter for this".

[Guillaume Deshors (g-deshors)]

Same exact problem for me ; xv stopped working with the "X11 error: BadAlloc" thing after upgrading to jaunty. Adding Driver 'intel' doesn't make any difference. Playing videos with x11 is awfully slow on this machine, sometimes even in 800x600, so it's not an acceptable fallback.
I'm convinced that this is related to the version of the intel driver ; I tried to downgrade but couldn't make X run with an older version. Couldn't the 8.10 version be backported and made available in jaunty as a workaround ? The bug is very annoying.

For info, part of lshw :

 *-pci
          description: Host bridge
          product: 82865G/PE/P DRAM Controller/Host-Hub Interface
          vendor: Intel Corporation
          physical id: 100
          bus info: pci@0000:00:00.0
          version: 02
          width: 32 bits
          clock: 33MHz
          configuration: driver=agpgart-intel module=intel_agp
        *-display UNCLAIMED
             description: VGA compatible controller
             product: 82865G Integrated Graphics Controller
             vendor: Intel Corporation
             physical id: 2
             bus info: pci@0000:00:02.0
             version: 02
             width: 32 bits
             clock: 33MHz
             capabilities: pm cap_list
             configuration: latency=0

[aosterhout (aosterhout)]

The fix described here:
http://ubuntuforums.org/showthread.php?t=1130582
may help some people. Video performance was greatly increased after updating to the 2.6.29 kernel, however this will break any restricted drivers.

[cleggton (mat-cleggville)]

On hardware:

00:02.0 VGA compatible controller [0300]: Intel Corporation 82945G/GZ Integrated Graphics Controller [8086:2772] (rev 02)

reverting to the 2.4 driver resolved the issue.

https://wiki.ubuntu.com/ReinhardTartler/X/RevertingIntelDriverTo2.4

I don't know how "safe" or generic this fix is, but it has fixed my "showstopper" for now.

[Rmcauley-gmail (rmcauley-gmail)]

As a user, I'm concerned what happens with > 2048 pixel setups in the next driver versions that rely on UXA and nothing else. I've tried UXA before on my dual monitor configuration (1280x1024 VGA + 1024x768 laptop) and get rejected for DRI not being available. (I'm not even trying to use Compiz - just DRI)

What will happen when I go to install Ubuntu Karmic, or use the xorg-edgers repository, and want to use dual monitors? Fall back to VESA framebuffer drivers?

Forgive any ignorance here, please. This is mostly an attempt by me to bring attention to (what is to me) a serious flaw in the drivers. I'm surprised this bug hasn't garnered more attention, since a quick google will show you countless posts on forums of people who have this problem.

[Gordon Jin (gordon-jin)]

(In reply to comment #11)
> As a user, I'm concerned what happens with > 2048 pixel setups in the next
> driver versions that rely on UXA and nothing else.

UXA is not supposed to change this bug, though UXA now has another problem in xserver (bug#21190).

[João Neves (jneves)]

Just noting that robertnull's workaround did not work here.

This is serious. I have a laptop, when connecting to an external projector, the screen properties screen increases the Virtual desktop to handle both the laptop and external screen. Results: no acceleration, no video, no simple way to go back to a functional system for a normal user.

Is anyone working on a fix to this?

Thanks you all,
João Miguel Neves

[phil (fongpwf)]

I see the same problem on my MSI Wind. Video playing worked on Intrepid and stopped after upgrading to Jaunty.
Video players show:
X11 error: BadAlloc (insufficient resources for operation)
Xorg.0.log shows:
(EE) intel(0): Failed to pin xv buffer

lspci:
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

[João Neves (jneves)]

phil, do you have the Virtual line in /etc/X11/xorg.conf?

[phil (fongpwf)]

I have a virtual size of 2304 1024 to accommodate a 1280x1024 monitor next to the internal 1024x600 screen.
After removing the virtual line, video playing works again.

[Bryce Harrington (bryce)]

Yes, the 2048 max width is a known issue on i945 and really is a hardware limitation, but we can track the upstream bug in case they come up with a clever solution some day.

The video players should probably not crash but rather display a friendly error message, but that's probably best handled via separate bug reports against each player.

[phil (fongpwf)]

Perhaps the xserver should not advertise the x-video extension when the virtual width is >2048? After all x-video won't work.

[Kehan Harman (kehan)]

I was getting this error and then realised that there were multiple users
with X sessions logged in to the machine (using the user switch applet) with
one of them being an automatic logon using GDM. I have since discovered that
the first person to log on (the automatic GDM one) can play video just fine,
while other users (X sessions) can't play video and get the BadAlloc error
(not sure about virtual width as this is a single head laptop). Apologies if
this isn't relevant to this bug.
Cheers,
Kehan

On Fri, Jul 10, 2009 at 7:28 AM, Bug Watch Updater <
<email address hidden>> wrote:

> ** Changed in: xserver-xorg-video-intel
> Status: Unknown => In Progress
>
> --
> [i945gm] all video players crash with BadAlloc error (no Compiz, Xv) if
> Virtual width > 2048.
> https://bugs.launchpad.net/bugs/359831
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Mactel Support: New
> Status in X.org xf86-video-intel: In Progress
> Status in “xserver-xorg-video-intel” package in Ubuntu: Triaged
>
> Bug description:
> Binary package hint: xserver-xorg-video-intel
>
> xine, mplayer, or totem all crash when attempting to play any video file
> with an error like this one from xine:
> This is xine (X11 gui) - a free video player v0.99.6cvs.
> (c) 2000-2007 The xine Team.
> X Error of failed request: BadAlloc (insufficient resources for operation)
> Major opcode of failed request: 132 (XVideo)
> Minor opcode of failed request: 19 ()
> Serial number of failed request: 4731
> Current serial number in output stream: 4732
>
> This worked in Intrepid and does not work since updating to the Jaunty beta
> this morning. I noticed it removing the xserver-xorg-video-i810 package and
> I can see other similar bugs saying that this has been deprecated in favor
> of xserver-xorg-video-intel.
>
> mplayer -vo x11 file.avi works, so it seems very likely this is an xvideo
> problem.
>
> One oddity: at first, 'mplayer file.avi' crashed immediately. After trying
> to run it and other video players a few times, now it opens a black window,
> plays the audio, and spams "X11 error: BadAlloc (insufficient resources for
> operation)" to console. I didn't change any settings (cross my heart), I was
> just hitting up and rerunning the last couple attempts to show someone in
> the room.
>
> ProblemType: Bug
> Architecture: i386, x86_64
> DistroRelease: Ubuntu 9.04
> Package: xserver-xorg-video-intel 2:2.6.3-0ubuntu9
> ProcEnviron:
> SHELL=/bin/bash
> PATH=(custom, user)
> LANG=en_US.UTF-8
> ProcVersion: Linux version 2.6.28-11-generic (buildd@rothera) (gcc version
> 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #41-Ubuntu SMP Wed Apr 8 04:38:53 UTC 2009
> SourcePackage: xserver-xorg-video-intel
> Uname: Linux 2.6.28-11-generic i686
>
> [lspci]
> 00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GM/PM/GMS,
> 943/940GML and 945GT Express Memory Controller Hub [8086:27a0] (rev 03)
> Subsystem: Intel Corporation Device [8086:7270]
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile
> 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2]
> (rev 03)
> Subsystem: Intel Corporation D...

[Russell Ault (russell-ault)]

I was getting this error on a clean install of Kubuntu Jaunty on a ThinkCentre with an Intel Corporation 82865G Integrated Graphics Controller (rev 02) with 32MB VRAM (maxed out in BIOS) with a single monitor running at 1680x1050. Dragon played back audio but with a solid blue block in place of the XVideo overlay, while VLC and the xine-ui simply exited with BadAlloc errors. I followed cleggton's instructions in post 18 above to revert back to Intel driver version 2.4 and the problem disappeared. Any idea what changed in the driver that would cause this problem?

[Gordon Jin (gordon-jin)]

This issue should have been fixed together with bug#21190 -- framebuffer has been increased to 4096 for i915/945 (with xf86-video-inte 2.8.0 and drm-intel-next kernel).

[Bryce Harrington (bryce)]

According to the upstream bug, the framebuffer width increase to 4096 makes this bug no longer occur. Peter, feel free to reopen if you find it still to be a problem in Alpha-5.

[Peter Bhat Harkins (pushcx)]

I attempted to test this bug but was unable to use my external monitor at all. I've reported Bug 430021 and will test when that bug is resolved.

[Mohammed Sayed (msayed2004)]

I upgraded to Karmic Koala but I can't use Intel driver, all what I get is 800*600 resolution also Compiz and media players can't work and nautilus crash after about 2 minutes!

I am using i810.

[Ivo Anjo (knuckles)]

Is this really fixed? This has been marked as fixed because bug #21190 was also fixed, but I think that other bug was just related to supporting 4096x4096 *without* DRI.

For something that was hard and needed shatter, it's strange to fix it with a diff that replaces 2048 with 4096.

I am using 2.6.31.6 and Intel Driver Version 2.8.1 and I can now put a 1680x1050 monitor to the right of my netbook 1024x600 panel (combined res 2704x1050).
But the minute I do that, kwin disables compositing, and I cannot re-enable it.

If I put the monitor below or above the netbook panel (combined res 1680x1650) compositing keeps working.

[Gordon Jin (gordon-jin)]

(In reply to comment #14)
> Is this really fixed? This has been marked as fixed because bug #21190 was also
> fixed, but I think that other bug was just related to supporting 4096x4096
> *without* DRI.

It should work (including DRI) if you use a non-compositing window manager like gnome. So I believe this old bug should be closed.

> I am using 2.6.31.6 and Intel Driver Version 2.8.1 and I can now put a
> 1680x1050 monitor to the right of my netbook 1024x600 panel (combined res
> 2704x1050).
> But the minute I do that, kwin disables compositing, and I cannot re-enable it.

For the compositing window manager issue, let's track at bug#23718.

[Ivo Anjo (knuckles)]

(In reply to comment #15)
> (In reply to comment #14)
> > Is this really fixed? This has been marked as fixed because bug #21190 was also
> > fixed, but I think that other bug was just related to supporting 4096x4096
> > *without* DRI.
>
> It should work (including DRI) if you use a non-compositing window manager like
> gnome. So I believe this old bug should be closed.
>
> > I am using 2.6.31.6 and Intel Driver Version 2.8.1 and I can now put a
> > 1680x1050 monitor to the right of my netbook 1024x600 panel (combined res
> > 2704x1050).
> > But the minute I do that, kwin disables compositing, and I cannot re-enable it.
>
> For the compositing window manager issue, let's track at bug#23718.
>

You are absolutely right. I was able to set a bigger-than 2048 resolution on my desktop, and then start openarena in windowed mode, and it still ran with DRI (up to 2047x2047).

I didn't think to test it before because I thought the compositing being disabled meant I'd lost DRI, but I was wrong.

Marking this bug as verified then.