iMX6Quad uart RX Fifo Overrun

[Salvatore1z]

Hi,

I'm using a custom made board with an iMX6Quad.

The Linux kernel version used is 3.14.28 and I see the following errors in dmesg:

[   58.250641] imx-uart 21ec000.serial: Rx FIFO overrun

[   59.241089] imx-uart 21ec000.serial: Rx FIFO overrun

[   59.246135] imx-uart 21ec000.serial: Rx FIFO overrun

[   59.251183] imx-uart 21ec000.serial: Rx FIFO overrun

[   60.241088] imx-uart 21ec000.serial: Rx FIFO overrun

[   60.246141] imx-uart 21ec000.serial: Rx FIFO overrun

[   60.251184] imx-uart 21ec000.serial: Rx FIFO overrun

The problem is not systematic.

I need some help to understand the source of the problem.

Any idea about the reason and why it is not systematic?

Thank you.

Salvatore

[Salvatore1z]

Hi,

I was able to fix the issue by backporting drivers/tty/serial/imx.c available in mainline kernel (3.18.26).

Thank you.

[hotiii]

I had the same problem and following above hints backported imx.c from mainline 3.14.63 kernel(a simple copy), then everything is ok. The L5.1.1_2.1.0-ga release has broken serial driver.

[viveksundarthir]

Hi, 

I am using the kernel version 3.10.17 for our application.  Intermittently I observe this issue.  I tried downloading the kernel version 3.18.26 from kernel.org and copied the imx.c file and compiled the kernel, but the basic communication itself did not work.  I guess that i am missing something.  Can you help me out in finding what I'm missing out? Or Can u just elaborate what you did to make it working?

Thanks,

Vivek 

[fabio_estevam]

This error message in the serial driver interrupt context can cause issues.

Please see this commit:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/tty/serial/imx.c?id=e... 

[igorpadykov]

Hi Salvatore

issue may be caused by processor latencies (due to heavy bus loading)

in servicing UART RX interrupts. Behaviour may be random, depending on

application, for alleviating problem one can try to use more powerful proccesor

(more cores, higher operating frequencies) or decreasing bus load, for example

decrease LCD resolution/freame rate, e.t.c.

Best regards

igor

-----------------------------------------------------------------------------------------------------------------------

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

-----------------------------------------------------------------------------------------------------------------------

[Salvatore1z]

Hello Igor,

thank you for your answer and your support.

I had a suspect about heavy bus loading for different reasons including that we are driving two displays with Wayland HMI.

Together with this problem I have also "AXI BUS ERROR" and "GPU Hang" errors (I opened other support requests for those), which I believe are all pointing to bus loading problems.

All these problems look random and sometimes the uart problem is present since the boot of out platform.

I was wondering if any tool is available to observe the bus usage in such a way to better understand bus loading issues.

I have already tried to use the maximum CPU operating frequency. To be more precise I disabled all but "performance governor" in the Kernel in such a way to be sure to always run the CPU at maximum frequency.

Anyway, I still reproduce the problem.

I will try descreasing display resolution and frame rate too.

In the meanwhile is there any documentation I can use to understand how to optimize bus usage?

Thank you.

Salvatore

[igorpadykov]

Hi Salvatore

one can try MMDC profiling tool

https://community.freescale.com/docs/DOC-94933

https://github.com/embeddedarm/android_external_imx-linux-test/commit/468f9227075f967d83a4839f376836...

~igor

[Salvatore1z]

Hello,

I was able to use the MMDC tool to do some memory bandwidth measurements.

In normal conditions with just the HMI running on the system I see "Overall bus load" in the range 21-66% (most of the time aound 21% with some peak at 66% for example while interacting with the HMI or when a GPU hang takes place) with a utilization which is almost always around 20-25%.

In the output I see that most of the bandwidth consumption, anyway, is related to two "objects" that the MMDC tool names "DSP1" and "DSP2".

Is it possible to understand what kind of objects "DSP1" and "DSP2" are and what function are they able to perform? Are those objects reporting NEON activities on the bus?

Moreover interacting with the HMI I see a x2 increase (70 MB/s to 150 MB/s) in bus load due to ARM cores and x15 increase (60 MB/S to 900 MB/s) due to GPU3D...while bus load due to DSP1 and DPS2 stays the same (120 MB/s and 290 MB/s) respectively.

I really can't explain myself the reason why going through an HMI menu could cause such bus load increase...Is there some object in the GPU pipeline that can be used to run some HMI related task?

Still a clarification...I guess that the object named "SUM" is an object that aggregates all the results to have a cumulative overview of bus load...am I correct?

Thank you.

Salvatore