topic Re: Video reentrancy issue in i.MX Processors

Video reentrancy issue

reuelhaavrahami — Mon, 16 Oct 2017 06:58:36 GMT

Hi All

We use among other video inputs/outputs GStreamer to play back video files. Most of the time it works fine and the video plays perfectly along with all the other video inputs/outputs. However at random intervals of time, the system would stop working. The GStreamer video (VideoX) is overlayed (hardware) with a Qt application (FramebufferY). Both are 1280x720. However, just before the system stops working, the Qt application output gets wildly stretched. At this point we start getting the following printouts

imx-ipuv3 2400000.ipu: IPU Warning - IPU_INT_STAT_5 = 0x08800000
imx-ipuv3 2400000.ipu: IPU Warning - IPU_INT_STAT_10 = 0x00100000

and after a small amount of time the system stops working completely (video) an we get the following

mxc_sdc_fb fb.24: timeout when waiting for flip irq

Interestingly when we start a playback with a new Gstreamer stream(different file) before the system gets to the "flip irq" error, the wild stretch of the Qt application sometimes gets fixed and the the system continues to work without any further errors.

When all stopped working, stopping and starting the involved processes (programs) will get the system to run again.

I have seen threads that state it is a performance issue. In our case it can hardly be the issue, as the CPU is at 40% usage when all the video parts in the system is running (Recording, playback, streaming, overlay, GUIs etc)

After some digging it seems like when calling mxcfb_set_par func() we sometimes get this problem. We could not see any change in the variables settings, and this leads us to conclude that there might be a reantrancy issue where some critical section is not protected as it should.

Can somebody help out to find this issue...? Thanks

Re: Video reentrancy issue

igorpadykov — Tue, 17 Oct 2017 07:26:26 GMT

Hi Reuel

imx-ipuv3 imx-ipuv3.0: IPU Warning - IPU_INT_STAT_10 = 0x00100000.
This means a synchronous display error interrupt, as a result of an error during
access to a synchronous display. one solution to this issue is reducing the use
case be reducing the display resolution, the needed framerate, frame buffer bits
per pixel or any other measure that helps to reduce the memory bandwidth utilization.

Also one can try to change IOMUXC_GPR6,7 with IPU QoS priorities.

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: Video reentrancy issue

reuelhaavrahami — Wed, 18 Oct 2017 07:56:30 GMT

Hi Igor

At the looks of it, I would agree with you - We get an oversized video output that the IPU should not be able to handle. This however is only a result of a deeper cause. We play back the same file time and again, but at random intervals we get this error. The fact that it works most of the time, already tells me that the system can handle the use case. The random errors is the issue.

When we do get this error, looking at the framebuffer that gets over-sized (by using fbset) gives the correct settings. which leads me to think that due to some reantrancy the IPU gets the wrong settings even though the fbset settings is correct.

Re: Video reentrancy issue

igorpadykov — Wed, 18 Oct 2017 08:25:19 GMT

Hi Reuel

one can try to add dmfc=3 in kernel boot parameters and increase IPU QoS priorities in IOMUXC_GPR6,7.

Best regards
igor

Re: Video reentrancy issue

reuelhaavrahami — Thu, 19 Oct 2017 09:55:04 GMT

Hi Igor

Setting the dmfc=3, we get video problems (rolling black and white lines through the picture) when all the programs run.

setting the IPU QoS to 0x007f007f did not help we still have the same problem.

I ran the DDR profiling tool "/unit_tests/mmdc2 SUM" and it show 44% without playback and 70% with playback.

Re: Video reentrancy issue

igorpadykov — Thu, 19 Oct 2017 10:34:42 GMT

Hi Reuel

70% is not small, one can try to decrease fps/resolution to verify that

this is not buses bandwidth issue.

Best regards
igor

Re: Video reentrancy issue

reuelhaavrahami — Thu, 19 Oct 2017 12:19:15 GMT

Hi Igor

I changed the timing settings of the vid/fb both (fbset) so that the framerate is lower than 3fps. We still get the IPU_INT_STAT_10 = 0x00100000 error.

I want to stress yet again. We don't get this all the time. After a random number of times playing the same files we would get this error. As soon as this happens we see the output stretched wildly out of proportion. I can understand getting this error due to the stretch of the picture, but I don't understand how does this stretch happen. So what I am trying to say is that - perhaps we should be looking into how the system gets WRONG settings so as to stretch the output that causes the errors...

Re: Video reentrancy issue

igorpadykov — Fri, 20 Oct 2017 00:10:15 GMT

Hi Reuel

what bsp used in the case, can issue be reproduced on nxp

reference board with bsps described on

i.MX 6 / i.MX 7 Series Software and Development Tool|NXP

Best regards
igor

Re: Video reentrancy issue

reuelhaavrahami — Sun, 22 Oct 2017 06:27:14 GMT

Hi Igor

Our board is similar to SabreSD, but has many changes. We started out using SabreSD BSP but by now is very different. We use the 3.14.52 kernel from Freescale. We have not tried to reproduce the issue on the devboards, since we use a camera input (720p 25fps), LCD output (LVDS with fb GUI overlay @ 720x480), HDMI output (720p), parallel output (with fb GUI overlay @ 720p). The playback is done on the parallel output where our issue comes into play....

The only development kit we have at the moment is a wandboard.

After I started to change the framerate output I noticed that sometimes it works, sometimes not, and sometimes I allways get the "mxc_sdc_fb fb.24: timeout when waiting for flip irq" error - depending on the settings. I changed the settings to an output of 25fps by adding right margin pixels and now I don't get the flip error. The system does not hang, but I still randomly get the

imx-ipuv3 2400000.ipu: IPU Warning - IPU_INT_STAT_5 = 0x08800000
imx-ipuv3 2400000.ipu: IPU Warning - IPU_INT_STAT_10 = 0x00100000

errors. I also still see the picture blown out of proportion big when we get these errors. When I try another playback after we get these errors, the error generally disappears and the output returns to its normal size.

Re: Video reentrancy issue

reuelhaavrahami — Sun, 29 Oct 2017 10:41:32 GMT

Hi Igor

Here is what I found so far.

I have a 800x480 output with video and overlay, and a 1280x720 output with video and overlay. I display two different GUI's to the overlays and a gstreamer fakesrc to the 800x480 video/fb. I wrote a small script to play a very short (3 seconds) video 300 times through gstreamer to the 1280x720 video/fb. We also get these same errors in this case at random intervals.

In the meantime I am going to test it also on the wandboard....

Re: Video reentrancy issue

igorpadykov — Sun, 29 Oct 2017 22:47:49 GMT

Hi Reuel

in general similar errors may happen if uboot logo enabled (so bypass_reset is true
and the IPU will not be fully initialized), please check uboot logo link:
https://community.nxp.com/docs/DOC-98109
Or play with various gpu memory settings, check sect.9.2 GPU memory attached
i.MX6 Graphics User's Guide, check that implemented clock switching procedure
described in EB821 LDB Clock Switch Procedure.
https://www.nxp.com/docs/en/engineering-bulletin/EB821.pdf
Another test may be use different IPUs and different clock sources to two displays.

Best regards
igor

Re: Video reentrancy issue

reuelhaavrahami — Wed, 01 Nov 2017 08:24:52 GMT

hi Igor

Thanks for the pointers. Some interesting points. I started out with changing clock sources. Running the same tests I found that changing the LVDS clock source from IMX6QDL_CLK_PLL2_PFD2_396M to IMX6QDL_CLK_PLL2_PFD0_352M in the dts fixes the issue. I ran 900 repetitions and now problems.