GStreamer crashing on i.MX6 (Boundary Devices Nitrogen6x)

Showing results for 
Search instead for 
Did you mean: 

GStreamer crashing on i.MX6 (Boundary Devices Nitrogen6x)

Jump to solution
Contributor III

Hi Everyone,

I've been developing an application for the new Boundary Devices Nitrogen6x board running an i.MX6Q processor. I'm using the Timesys BSP, kernel version: 3.0.35-ts-armv7l-2026-geaaf30e (LinuxLink Development Center for Boundary Devices Nitrogen6X | Timesys Embedded Linux). The application relies on GStreamer 0.10.36 and gst-fsl-plugin for playing MPEG-2 transport stream files that are H.264 encoded.

I ran into a problem playing back files that are around 2GB or larger. If I use playbin2 for the GStreamer pipeline and specify a large video file, the pipeline transitions to the preroll state and appears to identify the elements needed to play the video, but then it just sits there. I don't see any video output, not even the first frame of the video and within 30 seconds the program crashes stating it ran out of memory. This happens regardless of whether I use my program or use the gst-launch command.

On the other hand, if I construct the following pipeline, the video plays fine:

gst-launch filesrc location=video.ts ! tsdemux name=demux demux. ! queue max-size-buffers=0 max-size-time=0 ! vpudec ! mfw_v4lsink demux. ! queue max-size-buffers=0 max-size-time=0 ! mfw_mp3decoder ! audioconvert ! 'audio/x-raw-int,channels=2' ! alsasink

The problem is, I would rather use playbin2 because it offers more flexibility. I have encountered certain video files that will not play back using the pipeline above, but will with playbin2. I have compared a video that does playback and one that does not using gst-discoverer and see no difference; both are transport streams and both are H.264 encoded.

Can anyone offer any suggestions on how to get playbin2 to play these large video files?



Labels (3)
1 Solution
NXP Employee
NXP Employee

hi Jim& Lonsn,

     To DMA allocation issue, I have a patch, please try it, please remember ,  it's not the the formal patch from freescale.


View solution in original post

52 Replies
Contributor II

That's from the added GFP_NOFAIL in the patch.

If you remove the __GFP_NOFAIL flags that the patch added to files



the warning should go away. I don't know if that change is necessary for the patch to solve

your problem. Give it a try and let me know!



0 Kudos
Contributor III

Thanks Troy, removing that flag from those two files got rid of that warning.

Jack -- it looks like this patch resolved the memory allocation error. So far I've been running a test for about 3 hours and don't see any errors yet...



0 Kudos
Contributor III

Thanks Troy, I was able to apply that patch. I'll test this out tomorrow...


0 Kudos
Contributor III

Cool thanks Eric.


0 Kudos
Contributor I

I have tried this patch in my wandboard i.mx6 solo platform. Now there isn't old memory allocation issue. But I meet new question: the HDMI display will lose after 5-10 minutes video play. Just use following program:

gplay /tmp/video/snsd.avi /tmp/video/big_buck_bunny_1080p_H264_AAC_25fps_7200K.MP4

The gplay works OK except no HDMI output. Sometimes no any kernel output, and sometimes kernel output following:

[  693.069538] v4l2 alloc addr 0xa1000000

[  693.078847] v4l2 alloc addr 0xa1400000

[  693.088090] v4l2 alloc addr 0xa1800000

[  693.097241] v4l2 alloc addr 0xa1c00000

[  693.106415] v4l2 alloc addr 0xa2000000

[  693.115488] v4l2 alloc addr 0xa2400000

[  693.124742] v4l2 alloc addr 0xa2800000

[  693.133797] v4l2 alloc addr 0xa2c00000

[  693.142941] v4l2 alloc addr 0xa3000000

[  693.152059] v4l2 alloc addr 0xa3400000

[  693.238193] vqueue:src: page allocation failure: order:11, mode:0xd1

[  693.238204] Backtrace:

[  693.238260] [<800372d0>] (dump_backtrace+0x0/0x10c) from [<80390dec>] (dump_stack+0x18/0x1c)

[  693.238272]  r6:00000000 r5:000000d1 r4:00000001 r3:00000000

[  693.238300] [<80390dd4>] (dump_stack+0x0/0x1c) from [<8009be40>] (warn_alloc_failed+0xec/0x10c)

[  693.238321] [<8009bd54>] (warn_alloc_failed+0x0/0x10c) from [<8009e150>] (__alloc_pages_nodemask+0x5e8/0x640)

[  693.238333]  r3:00000000 r2:00000000

[  693.238343]  r7:0000000b r6:00000001 r5:81bf2000 r4:000000d1

[  693.238370] [<8009db68>] (__alloc_pages_nodemask+0x0/0x640) from [<8003a718>] (__dma_alloc+0xcc/0x2bc)

[  693.238391] [<8003a64c>] (__dma_alloc+0x0/0x2bc) from [<8003a994>] (dma_alloc_writecombine+0x28/0x34)

[  693.238416] [<8003a96c>] (dma_alloc_writecombine+0x0/0x34) from [<801b0bd4>] (mxcfb_set_par+0x224/0x66c)

[  693.238440] [<801b09b0>] (mxcfb_set_par+0x0/0x66c) from [<8019d7b0>] (fb_set_var+0x1a8/0x280)

[  693.238473] [<8019d608>] (fb_set_var+0x0/0x280) from [<8024edec>] (config_disp_output+0x150/0x420)

[  693.238495] [<8024ec9c>] (config_disp_output+0x0/0x420) from [<8024f580>] (mxc_vidioc_streamon+0x88/0x108)

[  693.238517] [<8024f4f8>] (mxc_vidioc_streamon+0x0/0x108) from [<80244ed4>] (__video_do_ioctl+0x2588/0x4e30)

[  693.238528]  r5:00000000 r4:00000002

[  693.238545] [<8024294c>] (__video_do_ioctl+0x0/0x4e30) from [<802426e0>] (video_usercopy+0x35c/0x4b8)

[  693.238564] [<80242384>] (video_usercopy+0x0/0x4b8) from [<80242850>] (video_ioctl2+0x14/0x1c)

[  693.238583] [<8024283c>] (video_ioctl2+0x0/0x1c) from [<80241970>] (v4l2_ioctl+0x70/0x11c)

[  693.238612] [<80241900>] (v4l2_ioctl+0x0/0x11c) from [<800cd308>] (do_vfs_ioctl+0x4ec/0x560)

[  693.238623]  r8:80033d04 r7:0000000c r6:94b071e0 r5:2f1e78a4 r4:920a1ca8

[  693.238640] r3:80241900

[  693.238657] [<800cce1c>] (do_vfs_ioctl+0x0/0x560) from [<800cd3bc>] (sys_ioctl+0x40/0x64)

[  693.238667]  r9:81bf2000 r8:80033d04 r7:0000000c r6:40045612 r5:2f1e78a4

[  693.238685] r4:94b071e0

[  693.238703] [<800cd37c>] (sys_ioctl+0x0/0x64) from [<80033b80>] (ret_fast_syscall+0x0/0x30)

[  693.238713]  r7:00000036 r6:2adfffb4 r5:2d37e1f0 r4:00121430

[  693.238728] Mem-info:

[  693.238735] Normal per-cpu:

[  693.238743] CPU    0: hi:   90, btch:  15 usd:   0

[  693.238764] active_anon:1333 inactive_anon:0 isolated_anon:0

[  693.238770]  active_file:4208 inactive_file:556 isolated_file:0

[  693.238776]  unevictable:118 dirty:0 writeback:0 unstable:0

[  693.238782]  free:38947 slab_reclaimable:261 slab_unreclaimable:951

[  693.238789]  mapped:1489 shmem:0 pagetables:102 bounce:0

[  693.238818] Normal free:155788kB min:1828kB low:2284kB high:2740kB active_anon:5332kB inactive_anon:0kB active_file:16832kB inactive_file:2224kB unevictable:472kB isolated(anon):0kB isolated(file):0kB present:208896kB mlocked:4kB dirty:0kB writeback:0kB mapped:5956kB shmem:0kB slab_reclaimable:1044kB slab_unreclaimable:3804kB kernel_stack:472kB pagetables:408kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no

[  693.238852] lowmem_reserve[]: 0 0 0

[  693.238862] Normal: 535*4kB 456*8kB 301*16kB 209*32kB 122*64kB 77*128kB 52*256kB 36*512kB 23*1024kB 16*2048kB 8*4096kB 0*8192kB 0*16384kB 0*32768kB = 155788kB

[  693.238901] 4886 total pagecache pages

[  693.261167] 131072 pages of RAM

[  693.261177] 39058 free pages

[  693.261183] 80149 reserved pages

[  693.261188] 651 slab pages

[  693.261194] 3298 pages shared

[  693.261199] 0 pages swap cached

[  693.261215] mxc_sdc_fb mxc_sdc_fb.0: Unable to allocate framebuffer memory

[  693.261227] detected fb_set_par error, error code: -12

[  693.594826] mxc_v4l2_output mxc_v4l2_output.0: ERR:config_disp_output fb_set_var ret:-12

[  693.605380] mxc_v4l2_output mxc_v4l2_output.0: Config display output failed

0 Kudos
Senior Contributor II

Do you sense a game of "whack a mole" starting here?

It seems that Jack's patch fixed the camera allocation, but not the video output

allocation here:

0 Kudos
Contributor I

When the HDMI output disappear, I need to do the following command:

echo 0 >/sys/class/graphics/fb0/blank

Then HDMI output comes back. But almost every 10 minutes, the HDMI output will disappear.

0 Kudos
Contributor II

Hi Ionsn

Have you tried passing "consoleblank=0" in your commandline bootargs?

0 Kudos
Contributor I

Yes, after I add the consoleblank=0 kernel parameter, the HDMI output is OK now.

Thanks a lot, Troy.

0 Kudos
Contributor III

Great thanks Jack. I'll give this patch a try!


0 Kudos
Senior Contributor II

Nicely done Jack!

I wasn't aware of the <tt>dma_declare_coherent_memory</tt> API call, and this fits the bill very nicely for those apps that know how much they need to reserve for video playback.

0 Kudos
Contributor I

I have the same issue with Jim. After cleaning the page cashes, I can play another video in my wandboard.

But sometimes the HDMI display will disappear with following message:

root@freescale ~$ [  467.207497] __dma_free_remap: trying to free invalid coherent area:   (null)

[  467.214574] Backtrace:

[  467.217220] [<800372d0>] (dump_backtrace+0x0/0x10c) from [<80390e2c>] (dump_stack+0x18/0x1c)

[  467.225835]  r6:00000000 r5:002fd000 r4:00000000 r3:00000001

[  467.231618] [<80390e14>] (dump_stack+0x0/0x1c) from [<8003ac7c>] (dma_free_coherent+0x80/0x1a0)

[  467.240404] [<8003abfc>] (dma_free_coherent+0x0/0x1a0) from [<80251ad8>] (videobuf_vm_close+0xa8/0xf0)

[  467.249786] [<80251a30>] (videobuf_vm_close+0x0/0xf0) from [<800aead0>] (remove_vma+0x30/0x70)

[  467.258466] [<800aeaa0>] (remove_vma+0x0/0x70) from [<800b013c>] (exit_mmap+0x208/0x224)

[  467.266649]  r5:00000001 r4:993f76e0

[  467.270308] [<800aff34>] (exit_mmap+0x0/0x224) from [<8005c4cc>] (mmput+0x3c/0xdc)

[  467.277926]  r5:00000000 r4:9c6bad00

[  467.281573] [<8005c490>] (mmput+0x0/0xdc) from [<8006065c>] (exit_mm+0x140/0x148)

[  467.289099]  r5:9c1c2000 r4:9c6bad00

[  467.292739] [<8006051c>] (exit_mm+0x0/0x148) from [<80061b48>] (do_exit+0x1b4/0x5d4)

[  467.300664]  r7:9c11e660 r6:9c6bad00 r5:00000009 r4:9c1c2000

[  467.306403] [<80061994>] (do_exit+0x0/0x5d4) from [<8006222c>] (do_group_exit+0x84/0xb0)

[  467.314497]  r7:9da94000

[  467.317064] [<800621a8>] (do_group_exit+0x0/0xb0) from [<8006ce68>] (get_signal_to_deliver+0x384/0x3c4)

[  467.326473]  r7:9da94000 r6:9da94000 r5:9da95ec8 r4:00418004

[  467.332198] [<8006cae4>] (get_signal_to_deliver+0x0/0x3c4) from [<800362e0>] (do_signal+0xac/0x530)

[  467.341266] [<80036234>] (do_signal+0x0/0x530) from [<80036cd4>] (do_notify_resume+0x20/0x58)

[  467.349813] [<80036cb4>] (do_notify_resume+0x0/0x58) from [<80033bd8>] (work_pending+0x24/0x28)

[  467.358524]  r4:00000028 r3:9da94000

[  467.363178] __dma_free_remap: trying to free invalid coherent area:   (null)

[  467.370277] Backtrace:

[  467.372758] [<800372d0>] (dump_backtrace+0x0/0x10c) from [<80390e2c>] (dump_stack+0x18/0x1c)

[  467.381214]  r6:00000000 r5:002fd000 r4:00000000 r3:00000003

[  467.386948] [<80390e14>] (dump_stack+0x0/0x1c) from [<8003ac7c>] (dma_free_coherent+0x80/0x1a0)

[  467.395668] [<8003abfc>] (dma_free_coherent+0x0/0x1a0) from [<80251ad8>] (videobuf_vm_close+0xa8/0xf0)

[  467.404987] [<80251a30>] (videobuf_vm_close+0x0/0xf0) from [<800aead0>] (remove_vma+0x30/0x70)

[  467.413646] [<800aeaa0>] (remove_vma+0x0/0x70) from [<800b013c>] (exit_mmap+0x208/0x224)

[  467.421753]  r5:00000001 r4:993f7790

[  467.425380] [<800aff34>] (exit_mmap+0x0/0x224) from [<8005c4cc>] (mmput+0x3c/0xdc)

[  467.432953]  r5:00000000 r4:9c6bad00

[  467.436596] [<8005c490>] (mmput+0x0/0xdc) from [<8006065c>] (exit_mm+0x140/0x148)

[  467.444082]  r5:9c1c2000 r4:9c6bad00

[  467.447703] [<8006051c>] (exit_mm+0x0/0x148) from [<80061b48>] (do_exit+0x1b4/0x5d4)

[  467.455460]  r7:9c11e660 r6:9c6bad00 r5:00000009 r4:9c1c2000

[  467.461180] [<80061994>] (do_exit+0x0/0x5d4) from [<8006222c>] (do_group_exit+0x84/0xb0)

[  467.469283]  r7:9da94000

[  467.471838] [<800621a8>] (do_group_exit+0x0/0xb0) from [<8006ce68>] (get_signal_to_deliver+0x384/0x3c4)

[  467.481245]  r7:9da94000 r6:9da94000 r5:9da95ec8 r4:00418004

[  467.486975] [<8006cae4>] (get_signal_to_deliver+0x0/0x3c4) from [<800362e0>] (do_signal+0xac/0x530)

[  467.496042] [<80036234>] (do_signal+0x0/0x530) from [<80036cd4>] (do_notify_resume+0x20/0x58)

[  467.504577] [<80036cb4>] (do_notify_resume+0x0/0x58) from [<80033bd8>] (work_pending+0x24/0x28)

[  467.513306]  r4:00000028 r3:9da94000

0 Kudos
Contributor III

I've continued running tests, trying to figure out how to get video playing reliably. What I've noticed is it seems that these errors and memory leaks stem from continuously creating and destroying GStreamer pipelines. As I understand from GStreamer's own documentation and the GStreamer community, the only way to change to another video is to destroy the current pipeline and create a new one. As I said in my last post, I created a Qt test program that utilizes Phonon for video playback (GStreamer as its backend) to rule out me improperly using the GStreamer library.

If I just let a video play in a loop, meaning once I get the EOS message from GStreamer, I perform a seek to the beginning, I don't see any kernel errors and there doesn't seem to be any memory leak. Again, I'm testing this using the gst-tester program that I attached in my last post and playing an MPEG-2 transport stream file. I'm using the tsdemux element from gst-plugins-bad since aiurdemux doesn't work with >=2GB files.

There's got to be some way to reliably switch to another video. I would really appreciate anyone's help, our product is based on the i.MX6 and its soul purpose is to allow the user to play videos. As it stands now, it could probably only run for MAYBE an hour before needing to restart the system, which is unacceptable.

Thanks, Jim

0 Kudos
Senior Contributor II

Hi Jim,

What's the origin of your Qt/Phonon? Rogerio posted some patches for a leak in that

platform on the Yocto ML.

0 Kudos
Contributor III

It's from the Timesys Nitrogen6x BSP. I looked at the patches in the Qt build directory and found the attached patch which I believe is what that post refers to. I also have checked the open file descriptors while the program is running: ls -l /proc/`pidof phononPlayer`/fd | grep /dev/video and only see one instance of /dev/video17.


Senior Contributor II

Thanks Jim,

I knew that Timesys integrated those patches, but hadn't tested them myself.

0 Kudos
Contributor III

Hi Junping,

I'm still having problems playing video reliably. I wrote 2 test programs with Qt 4.8.3; one uses the GStreamer library directly and the other uses Phonon which uses GStreamer as its backend. I created the Phonon version to make sure I wasn't causing a memory leak with my handling of the GStreamer library. Both versions are causing the kernel errors eventually and both appear to be leaking memory.

I first thought maybe there was a problem with the MPEG-2 transport streams I was using, or just with playing transport streams in general. But I downloaded 4 public domain videos that are avi's with DivX MPEG-4 encoding. These also cause the same problem.

I've attached my test code, each one has a README that explains how to configure it. I've also included the links to the public domain movies I used.

I don't know how much showing the properties of one of my videos will help, but kmplayer would not play a TS file so I used gst-discoverer:

Analyzing file:///media/sda1/video.ts

Aiur: 3.0.1

Core: BLN_MAD-MMLAYER_MPG2PARSER_ARM11_04.03.09  build on Aug 24 2012 10:57:23

  mime: video/mpeg, mpegversion=(int)[1,2]; video/mpegts, systemstream=true; video/x-cdxa

  file: /usr/lib/imx-mm/parser/

Content Info:



    Idx File:


    Seekable  : Yes

    Size(byte): 930524800

Mpeg2CreateParser:parser created successfully

Movie Info:

    Seekable  : Yes

    Live      : No

    Duration  : 1:34:59.293600000

    ReadMode  : File

    programs    : 1

    Track    : 2

Track 00 [video_0010] Enabled

    Duration: 1:34:59.293600000



          video/x-h264, parsed=(boolean)true, width=(int)720, height=(int)480, framerate=(

          fraction)30/1, codec_data=(buffer)0000016764001facd940b43dbff0020001b100000303e9


[INFO]    Product Info: i.MX6Q/D/S

vpudec versions :smileyhappy:

    plugin: 3.0.1

    wrapper: 1.0.24(VPUWRAPPER_ARM_LINUX Build on Feb 18 2013 13:46:34)

    vpulib: 5.4.6


Track 01 [audio_0010] Enabled

    Duration: 1:34:59.232000000



          audio/mpeg, mpegversion=(int)1, parsed=(boolean)true, framed=(boolean)true, chan

          nels=(int)2, rate=(int)48000, bitrate=(int)128

[INFO]    bitstreamMode 1, chromaInterleave 1, mapType 0, tiled2LinearEnable 0

Beep: 3.0.1

Core: MP3 decoder Wrapper  build on Aug 16 2012 14:43:01

  mime: audio/mpeg, mpegversion = (int)1

  file: /usr/lib/imx-mm/audio-codec/wrap/

CODEC: BLN_MAD-MMCODECS_MP3D_ARM_02.11.00_CORTEX-A8  build on Jul 16 2012 14:38:49.

[--->FINALIZE aiurdemux

Done discovering file:///media/sda1/video.ts


  container: MPEG-2 Transport Stream

    audio: MPEG-1 Layer 2 (MP2)

    video: H.264


  Duration: 1:34:59.293600000

  Seekable: yes


      codec: { H.264/AVC, MP3 }

      container format: MPEG

      bitrate: 128

      audio codec: MPEG 1 Audio, Layer 2

      nominal bitrate: 128000

      has crc: false

      channel mode: stereo

      minimum bitrate: 128000

      maximum bitrate: 128000

      number of channels: 2

      sampling frequency (Hz): 48000



Message was edited by: Jim Heath I updated the gst-tester.tar.gz after noticing a bug when only a single video is in the playlist. Also included a more general .pro file so it will compile with the Timesys toolchain.

0 Kudos
Contributor II

Hi Jim,

      I want install Qt4.8.3 on mx6, play video with GStreamer lib, can you help me?

I build ltib succeeded with GStreamer lib (gstreamer,gstreamer-plugins-base,gstreamer-plugins-good,gstreamer-plugins-bad,gstreamer-plugins-ugly).

but don't know how to build Qt?

I build the Linux BSP (L3.0.35_4.0.0).

Host PC: Ubuntu 10.04


0 Kudos
Contributor III

I used the i.MX6 BSP from Timesys: to build everything, including Qt.


0 Kudos
NXP Employee
NXP Employee


   From the video property, the stream should be ok for playback,  I notice that you use element from gst-plugins-bad, those plugin maybe have potential issues, please consider base and good plugins.

    if you can use playbin2 to playback the video stream, you could  export GST_DEBUG=GST_ELEMENT_FACTORY:3   to look what elements used by playbin2, then you maybe re-org your pipeline

0 Kudos
Contributor III

Here is another test program I wrote that demonstrates the problem. This one is written purely in C. The attachment includes the source code and a shell script for running the test in an infinite loop. The script instructs the program to use playbin2 which selects the aiurdemux element. It uses the public domain videos:

I'm using the Timesys Nitrogen6x BSP.

When I started this test, video was working fine but after 8 hours of execution (I ran it overnight) I woke up the next morning to no video. At that point, every time the program would execute, the following kernel errors were showing up:

multiqueue0:src: page allocation failure: order:7, mode:0x1 [<80100e08>] (unwind_backtrace+0x0/0xf8) from [<80175410>] (warn_alloc_failed+0xc8/0x100) [<80175410>] (warn_alloc_failed+0xc8/0x100) from [<8017795c>] (__alloc_pages_nodemask+0x4c8/0x6cc)

[<8017795c>] (__alloc_pages_nodemask+0x4c8/0x6cc) from [<80103d80>] (__dma_alloc+0xa4/0x300) [<80103d80>] (__dma_alloc+0xa4/0x300) from [<801045b8>] (dma_alloc_coherent+0x54/0x60) [<801045b8>] (dma_alloc_coherent+0x54/0x60) from [<8043e800>] (__videobuf_mmap_mapper+0x8c/0x194)

[<8043e800>] (__videobuf_mmap_mapper+0x8c/0x194) from [<8043cddc>] (videobuf_mmap_mapper+0xbc/0x11c) [<8043cddc>] (videobuf_mmap_mapper+0xbc/0x11c) from [<80439fdc>] (mxc_vout_mmap+0x20/0x54) [<80439fdc>] (mxc_vout_mmap+0x20/0x54) from [<8042bed8>] (v4l2_mmap+0x98/0xa4) [<8042bed8>] (v4l2_mmap+0x98/0xa4) from [<8018fd00>] (mmap_region+0x2d4/0x458) [<8018fd00>] (mmap_region+0x2d4/0x458) from [<80190248>] (sys_mmap_pgoff+0x78/0xc0) [<80190248>] (sys_mmap_pgoff+0x78/0xc0) from [<800f9f40>] (ret_fast_syscall+0x0/0x30)


DMA per-cpu:

CPU    0: hi:   90, btch: 15 usd:   2

CPU    1: hi:   90, btch: 15 usd:  80

CPU    2: hi:   90, btch: 15 usd:  87

CPU    3: hi:   90, btch: 15 usd:  71

Normal per-cpu:

CPU    0: hi:  186, btch: 31 usd:  74

CPU    1: hi:  186, btch: 31 usd: 163

CPU    2: hi:  186, btch: 31 usd: 116

CPU    3: hi:  186, btch: 31 usd: 151

active_anon:1441 inactive_anon:3 isolated_anon:0

active_file:35378 inactive_file:172504 isolated_file:0

unevictable:0 dirty:1 writeback:0 unstable:0

free:8624 slab_reclaimable:963 slab_unreclaimable:1197

mapped:1439 shmem:3 pagetables:45 bounce:0 DMA free:28192kB min:780kB low:972kB high:1168kB active_anon:2300kB inactive_anon:8kB active_file:3680kB inactive_file:133340kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:186944kB mlocked:0kB dirty:0kB writeback:0kB mapped:8kB shmem:8kB slab_reclaimable:236kB slab_unreclaimable:48kB kernel_stack:56kB pagetables:12kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no

lowmem_reserve[]: 0 705 705 705

Normal free:6304kB min:3028kB low:3784kB high:4540kB active_anon:3464kB inactive_anon:4kB active_file:137832kB inactive_file:556676kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:722368kB mlocked:0kB dirty:4kB writeback:0kB mapped:5772kB shmem:4kB slab_reclaimable:3616kB slab_unreclaimable:4740kB kernel_stack:504kB pagetables:168kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:1 all_unreclaimable? no

lowmem_reserve[]: 0 0 0 0

DMA: 198*4kB 115*8kB 83*16kB 64*32kB 63*64kB 93*128kB 24*256kB 2*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB 0*32768kB = 28192kB

Normal: 178*4kB 153*8kB 81*16kB 26*32kB 13*64kB 11*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB 0*32768kB = 6304kB

207905 total pagecache pages

0 pages in swap cache

Swap cache stats: add 0, delete 0, find 0/0 Free swap  = 0kB Total swap = 0kB

262144 pages of RAM

9456 free pages

36933 reserved pages

1065 slab pages

4098 pages shared

0 pages swap cached

mxc_v4l2_output mxc_v4l2_output.0: dma_alloc_coherent size 274432 failed mxc_v4l2_output mxc_v4l2_output.0: offset invalid [offset=0x29e000]

__dma_free_remap: trying to free invalid coherent area:   (null)

[<80100e08>] (unwind_backtrace+0x0/0xf8) from [<80104444>] (dma_free_coherent+0x17c/0x1c4) [<80104444>] (dma_free_coherent+0x17c/0x1c4) from [<8043e6c8>] (videobuf_vm_close+0x94/0x10c) [<8043e6c8>] (videobuf_vm_close+0x94/0x10c) from [<8018e3b4>] (remove_vma+0x28/0x80) [<8018e3b4>] (remove_vma+0x28/0x80) from [<8018f528>] (do_munmap+0x248/0x2a4) [<8018f528>] (do_munmap+0x248/0x2a4) from [<801907dc>] (sys_munmap+0x3c/0x50) [<801907dc>] (sys_munmap+0x3c/0x50) from [<800f9f40>] (ret_fast_syscall+0x0/0x30)

__dma_free_remap: trying to free invalid coherent area:   (null)

[<80100e08>] (unwind_backtrace+0x0/0xf8) from [<80104444>] (dma_free_coherent+0x17c/0x1c4) [<80104444>] (dma_free_coherent+0x17c/0x1c4) from [<8043e6c8>] (videobuf_vm_close+0x94/0x10c) [<8043e6c8>] (videobuf_vm_close+0x94/0x10c) from [<8018e3b4>] (remove_vma+0x28/0x80) [<8018e3b4>] (remove_vma+0x28/0x80) from [<8018f528>] (do_munmap+0x248/0x2a4) [<8018f528>] (do_munmap+0x248/0x2a4) from [<801907dc>] (sys_munmap+0x3c/0x50) [<801907dc>] (sys_munmap+0x3c/0x50) from [<800f9f40>] (ret_fast_syscall+0x0/0x30)

__dma_free_remap: trying to free invalid coherent area:   (null)

[<80100e08>] (unwind_backtrace+0x0/0xf8) from [<80104444>] (dma_free_coherent+0x17c/0x1c4) [<80104444>] (dma_free_coherent+0x17c/0x1c4) from [<8043e6c8>] (videobuf_vm_close+0x94/0x10c) [<8043e6c8>] (videobuf_vm_close+0x94/0x10c) from [<8018e3b4>] (remove_vma+0x28/0x80) [<8018e3b4>] (remove_vma+0x28/0x80) from [<8018f528>] (do_munmap+0x248/0x2a4) [<8018f528>] (do_munmap+0x248/0x2a4) from [<801907dc>] (sys_munmap+0x3c/0x50) [<801907dc>] (sys_munmap+0x3c/0x50) from [<800f9f40>] (ret_fast_syscall+0x0/0x30)

__dma_free_remap: trying to free invalid coherent area:   (null)

[<80100e08>] (unwind_backtrace+0x0/0xf8) from [<80104444>] (dma_free_coherent+0x17c/0x1c4) [<80104444>] (dma_free_coherent+0x17c/0x1c4) from [<8043e6c8>] (videobuf_vm_close+0x94/0x10c) [<8043e6c8>] (videobuf_vm_close+0x94/0x10c) from [<8018e3b4>] (remove_vma+0x28/0x80) [<8018e3b4>] (remove_vma+0x28/0x80) from [<8018f528>] (do_munmap+0x248/0x2a4) [<8018f528>] (do_munmap+0x248/0x2a4) from [<801907dc>] (sys_munmap+0x3c/0x50) [<801907dc>] (sys_munmap+0x3c/0x50) from [<800f9f40>] (ret_fast_syscall+0x0/0x30)

0 Kudos