Regression: serial: imx: overrun errors on debug UART
Sergey Organov
sorganov at gmail.com
Mon Apr 17 09:50:09 PDT 2023
Hi Stefan,
Stefan Wahren <stefan.wahren at i2se.com> writes:
> Hi Sergey,
>
[...]
> i had some time today to investigate this a little bit. I thought it
> would be a good idea to use debugfs as a ugly quick hack:
>
[...]
> Using this i was able to better compare the behavior with RXTL_DEFAULT
> 1 (without overrun errors) and RXTL_DEFAULT 8 (with overrun errors) on
> my i.MX6ULL test platform. After doing my usual test scenario (copy
> some text lines to console) i got the following results:
>
> RXTL_DEFAULT 1
> 21f0000.serial/stats:total_duration_us: 61
> 21f0000.serial/stats:rx_duration_us: 36
> 21f0000.serial/stats:tx_duration_us: 48
> 21f0000.serial/stats:received: 28
> 21f0000.serial/stats:send: 33
>
> RXTL_DEFAULT 8
> 21f0000.serial/stats:total_duration_us: 78
> 21f0000.serial/stats:rx_duration_us: 46
> 21f0000.serial/stats:tx_duration_us: 47
> 21f0000.serial/stats:received: 33
> 21f0000.serial/stats:send: 33
>
> So based on the maximum of received characters on RX interrupt, i
> consider the root cause of this issue has already been there because
> the amount is near to the maximum of the FIFO (32 chars). So finally
> increasing RXTL_DEFAULT makes the situation even worse by adding
> enough latency for overrun errors.
Yep, looks like an issue.
What's the baud rate? 115200? If so, it means that interrupts are
apparently blocked in your system for up to about 28/(115200/10)=2.4
milliseconds. This is very large number, and it may negatively affect
system performance in other places as well, I'm afraid.
Best regards,
-- Sergey Organov
More information about the linux-arm-kernel
mailing list