AnsweredAssumed Answered

i.MX6 Memory issues after long encoding

Question asked by Jarrod Cook on May 9, 2018
Latest reply on May 18, 2018 by Jarrod Cook


So i have a recording device using an i.MX 6 Solo and it encodes to h264 video.  The problem is that after i record for awhile i cannot start a new recording because I get memory errors.  For example if i record for 25 minutes straight i have no issues during the recording but as soon as that recording is stopped i cannot start another one without getting a memory crash:


cam-source:src: page allocation failure: order:9, mode:0xd1
CPU: 0 PID: 16107 Comm: cam-source:src Not tainted 4.1.15-0.3-224221-g6bef30f-dirty #29
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[<80015904>] (unwind_backtrace) from [<80011b7c>] (show_stack+0x10/0x14)
[<80011b7c>] (show_stack) from [<80658220>] (dump_stack+0x6c/0xb4)
[<80658220>] (dump_stack) from [<800a26b0>] (warn_alloc_failed+0xe8/0x114)
[<800a26b0>] (warn_alloc_failed) from [<800a4f44>] (__alloc_pages_nodemask+0x5fc/0x788)
[<800a4f44>] (__alloc_pages_nodemask) from [<8001a16c>] (__dma_alloc_buffer+0x2c/0x168)
[<8001a16c>] (__dma_alloc_buffer) from [<8001a444>] (__dma_alloc+0x19c/0x258)
[<8001a444>] (__dma_alloc) from [<8001a620>] (arm_dma_alloc+0x84/0x90)
[<8001a620>] (arm_dma_alloc) from [<8046a8bc>] (mxc_v4l_do_ioctl+0x132c/0x1bc4)
[<8046a8bc>] (mxc_v4l_do_ioctl) from [<80451da4>] (video_usercopy+0x230/0x3f4)
[<80451da4>] (video_usercopy) from [<8044d51c>] (v4l2_ioctl+0x5c/0x114)
[<8044d51c>] (v4l2_ioctl) from [<800e3e30>] (do_vfs_ioctl+0x4ec/0x5b0)
[<800e3e30>] (do_vfs_ioctl) from [<800e3f28>] (SyS_ioctl+0x34/0x5c)
[<800e3f28>] (SyS_ioctl) from [<8000eb40>] (ret_fast_syscall+0x0/0x3c)
active_anon:1399 inactive_anon:19380 isolated_anon:0
active_file:3833 inactive_file:12905 isolated_file:0
unevictable:1 dirty:1 writeback:0 unstable:0
slab_reclaimable:549 slab_unreclaimable:907
mapped:2149 shmem:19390 pagetables:70 bounce:0
free:2857 free_pcp:76 free_cma:0
Normal free:11428kB min:1704kB low:2128kB high:2556kB active_anon:5596kB inactive_anon:77520kB active_file:15332kB inactive_file:51620kB unevictable:4kB isolated(anon):0kB isolated(file):0kB present:524288kB managed:182068kB mlocked:4kB dirty:4kB writeback:0kB mapped:8596kB shmem:77560kB slab_reclaimable:2196kB slab_unreclaimable:3628kB kernel_stack:584kB pagetables:280kB unstable:0kB bounce:0kB free_pcp:304kB local_pcp:304kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
Normal: 335*4kB (MR) 225*8kB (UMR) 118*16kB (UMR) 56*32kB (U) 28*64kB (U) 8*128kB (UMR) 1*256kB (R) 1*512kB (R) 1*1024kB (R) 0*2048kB 0*4096kB 0*8192kB 0*16384kB 0*32768kB = 11428kB
36127 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap = 0kB
Total swap = 0kB
131072 pages RAM
0 pages HighMem/MovableOnly
85555 pages reserved
0 pages cma reserved
ERROR: v4l2 capture: mxc_allocate_frame_buf failed.
GST Error: Internal data flow error.


I added this call after the end of every recording:

echo 3 | tee /proc/sys/vm/drop_caches


And it helped immensely because before that it would happen even after a couple short recordings, so now it takes longer to get the issues but it still happens : /.  It is like the encoder is has a leak and is slowly taking all the CMA memory and then eventually I don't have a enough left to start a new recording process!  


I am running the rel_imx_4.1.15_1.1.0_ga kernel.


Any ideas?