Change VMETA_MEM_SIZE to 96 to support 1080p videos

This bug was fixed in the package linux-mvl-dove - 2.6.32-201.8

---------------
linux-mvl-dove (2.6.32-201.8) lucid; urgency=low

  [ Andy Whitcroft ]

  * rebase to Ubuntu-2.6.32-13.18

  [ Eric Miao ]

  * [Config]: CONFIG_UIO_DOVE_VMETA_MEM_SIZE=96 for 1080p playback
    - LP: #452558

  [ Ubuntu: 2.6.32-13.18 ]

  * Revert "enforcer -- make the enforcement configuration common"
  * Revert "(pre-stable) Input: ALPS - add interleaved protocol support
    (Dell E6x00 series)"
  * Revert "(pre-stable) driver-core: fix devtmpfs crash on s390"
  * Revert "(pre-stable) Driver-Core: devtmpfs - set root directory mode to
    0755"
  * Revert "SAUCE: Adds support for COMPAL JHL90 webcam"
  * Revert "SAUCE: fix kernel oops in VirtualBox during paravirt patching"
  * Revert "SAUCE: make fc transport removal of target configurable"
  * enforcer -- make the enforcement configuration common
  * getabis -- add preempt flavour to the list
  * [Config] enforce DEVTMPFS options
  * [Config] armel -- cleanup to-be builtin modules
  * [Config] cleanup ports configs
  * [Config] enable CRYPTO_GHASH_CLMUL_NI_INTEL
    - LP: #485536
  * add printdebian target to find branch target
  * distclean -- do not remove debian.env
  * [Config] generic-pae switch to M586TSC
    - LP: #519448
  * git-ubuntu-log -- commonise duplicated log handling
  * git-ubuntu-log -- tighten up Bug: NNNN matching
  * git-ubuntu-log -- sort the bug numbers
  * (pre-stable) drm/i915: Increase fb alignment to 64k
    - LP: #404064
  * arm -- enable ubuntu/ directory
  * SAUCE: crypto: ghash - Add PCLMULQDQ accelerated implementation
  * SAUCE: crypto: ghash-intel - Fix building failure on x86_32
  * [Config] cleanup preempt configuration
  * [Config] versatile: Fix video output
    - LP: #517594
  * [Config] armel DEFAULT_MMAP_MIN_ADDR=32768
  * [Config] Large update to armel/versatile
  * [Config] versatile: Add RTC support
  * [Config] armel: Enable NEON
  * [Config] versatile: Builtin MMC support
  * [Config] versatile Builtin SCSI controller
  * [Config] armel Disable dma_cache_sync callers
  * [Config] armel Disable asm/time.h users
  * [Config] armel Disable out of range udelay()
  * [Config] armel Disable flush_cache_range() users
  * [Config] armel -- Enable ubuntu/ drivers
  * SAUCE: drm/i915: Add display hotplug event on Ironlake
  * SAUCE: drm/i915: Add ACPI OpRegion support for Ironlake
  * Revert "[Upstream]: oprofile/x86: add Xeon 7500 series support"
  * Revert "Revert "[Bluetooth] Eliminate checks for impossible conditions
    in IRQ handler""
  * clockevent: Don't remove broadcast device when cpu is dead
  * clockevents: Add missing include to pacify sparse
  * ACPI: don't cond_resched if irq is disabled
  * be2net: Add support for next generation of BladeEngine device.
  * be2net: Add the new PCI IDs to PCI_DEVICE_TABLE.
  * mpt2sas: New device SAS2208 support is added
  * ar9170: Add support for D-Link DWA 160 A2
  * powerpc/fsl: Add PCI device ids for new QoirQ chips
  * davinci: dm646x: Add support for 3.x silicon revision
  * Input: ALPS - add interleaved protocol support (Dell E6x00 series)
  * Driver-Core: devtmpfs - set root directory mode to 0755
  * driver-core: ...

There is an SRU upload for this in the queue, but this bug does not have ubuntu-sru subscribed (done now), nor an explanation of the impact, and, most importantly, the regression potential. What is the "VMETA memory size"? Why was the previous default as it was? What potential negative effect can it have to bump it?

vMeta, the HW video accelerator, has to use physical continuous memory. This "VMETA memory size" will have kernel reserve a block of DDR memory for video playback. The typical H.264 streams would cost <= 64MB DDR to decode while the most complex 1080p H.264 streams with 16 reference frames would cost up to 96MB DDR.

The negative impact is to have less free memory because the reserved memory is not controlled by kernel any longer.

The size of reserved memory could be changed by adding boot parameter "vmeta_size=n" (e.g. vmeta_size=96 ) when booting kernel from uboot.

Sorry, forget the last sentence of the previous comment about "vmeta_size=n", which is not supported any longer.

Thanks. That essentially means that this would suddenly take away 80 MB of RAM on those systems, right? Wouldn't that impact other desktop operations on low-memory systems? How much RAM do these machines have usually? If it's only 256 or 512, 80 MB would mean a significant portion of RAM?

Karmic has long since stopped to receive any updates. Marking the Karmic task for this ticket as "Won't Fix".