From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 65166E00C7E; Tue, 22 Dec 2015 04:17:13 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.0 SPF_HELO_PASS SPF: HELO matches SPF record * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Received: from ptmx.org (ptmx.org [178.63.28.110]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id EF3A5E00956 for ; Tue, 22 Dec 2015 04:17:09 -0800 (PST) Received: from [10.1.14.248] (vpn.streamunlimited.com [91.114.0.140]) by ptmx.org (Postfix) with ESMTPSA id 6D1A633FFD; Tue, 22 Dec 2015 13:17:06 +0100 (CET) To: Vikas Patil References: <564B3FD3.1030607@pseudoterminal.org> <564B5C5E.60309@pseudoterminal.org> <564C78B6.2000700@pseudoterminal.org> <564CAE4C.3040005@pseudoterminal.org> <56784D25.3040608@pseudoterminal.org> <56791C77.1050001@pseudoterminal.org> <567928F2.4070709@pseudoterminal.org> From: Carlos Rafael Giani Message-ID: <56793F40.7090407@pseudoterminal.org> Date: Tue, 22 Dec 2015 13:17:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Cc: meta-freescale@yoctoproject.org Subject: Re: imxvpudec crash with 3.14.28 and gstreamer1.0 X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 12:17:13 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit This is strange. For me, it looped over 160 times before I stopped it. I'll compare your config to that of the boundarydevices kernel. (Also note that this kernel might have patches that yours doesn't.) Try to repeatedly print out the contents of /proc/buddyinfo, especially the DMA row. I did, and the bins stayed relatively stable. If these bins rapidly decrease for you, then we might be looking at a kernel issue, or a problem with imx-vpu. On 12/22/2015 12:16 PM, Vikas Patil wrote: > Hi Carlos, > > Yes. After reconfiguration saw memory allocation failure after 35th loop. > > Attached here the complete log with allocation failure after 53rd time > with master branch of plug-in and libimxvpuapi and CMA configs I > mentioned. > > Regards, > Vikash > > > > On Tue, Dec 22, 2015 at 4:11 PM, Carlos Rafael Giani > wrote: >> You mean, "before the CMA reconfiguration, the loop-video test failed in the >> 5th loop, but after reconfiguration, it still runs after the 37th loop"? >> >> >> On 2015-12-22 11:19, Vikas Patil wrote: >>> Hi Carlos, >>> >>> I could run the video and see the output on dislay after commenting >>> libgstimxaudio.so but only one loop. Attached here the log. >>> >>> Also after enabling following kernel configs I could run the videotest >>> player application which I have till 37th loop before it was failing >>> in 5th loop itself. >>> >>> CONFIG_DMA_CMA=y >>> # >>> # Default contiguous memory area size: >>> # >>> CONFIG_CMA_SIZE_MBYTES=256 >>> CONFIG_CMA_SIZE_SEL_MBYTES=y >>> # CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set >>> # CONFIG_CMA_SIZE_SEL_MIN is not set >>> # CONFIG_CMA_SIZE_SEL_MAX is not set >>> CONFIG_CMA_ALIGNMENT=8 >>> CONFIG_CMA_AREAS=7 >>> >>> Regards, >>> Vikas >>> >>> On Tue, Dec 22, 2015 at 3:18 PM, Carlos Rafael Giani >>> wrote: >>>> This is a different error, however. It seems to be caused by an AAC >>>> decoding >>>> issue. Try removing the libgstimxaudio.so file from /usr/lib/ on your >>>> device. Note that you will need another AAC decoder then. gst-libav can >>>> decode AAC. So can the libgstfaad plugin (part of gst-plugins-bad). >>>> >>>> Would it also be possible for you to give me a copy of this >>>> B01_Baseline1.0_1280_720.MP4 file? >>>> >>>> >>>> On 2015-12-22 10:39, Vikas Patil wrote: >>>>> Hi Carlos, >>>>> >>>>> Still I could not play. Attached here the log. >>>>> >>>>> Regards, >>>>> Vikas >>>>> >>>>> On Tue, Dec 22, 2015 at 12:34 AM, Carlos Rafael Giani >>>>> wrote: >>>>>> Can you try out the example program I attached? Just run it like this: >>>>>> >>>>>> GST_DEBUG=2,*imx*:5 ./loop-videos -i 5000 -v "imxipuvideotransform ! >>>>>> imxeglvivsink" /home/root/B01_Baseline1.0_1280_720.MP4 >>>>>> >>>>>> This will run the mp4 video for 5 seconds and then start again. Note >>>>>> that >>>>>> you have to build it with the -std=c++11 compiler flag. > >