Regression: serial: imx: overrun errors on debug UART

[Linux regression tracking (Thorsten Leemhuis)]

Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.

Stefan, was this regression ever solved? It doesn't look like it, but
maybe I'm missing something.

If it wasn't solved: what needs to be done to get this rolling again?

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

#regzbot poke

On 18.04.23 18:16, Stefan Wahren wrote:
> Hi Sergey,
> 
> Am 17.04.23 um 18:50 schrieb Sergey Organov:
>> 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.
> 
> i forgot to mention that i also measured the time around
> printk_safe_(enter|exit)_irqsave in console_emit_next_record() which had
> a maximum of 24721 µs. But uncommenting these functions doesn't fixed
> the problem. This seems to be used only by printk.
> 
> Best regards
> 
>>
>> Best regards,
>> -- Sergey Organov
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel