Regression: serial: imx: overrun errors on debug UART
Stefan Wahren
stefan.wahren at i2se.com
Tue Apr 18 09:16:34 PDT 2023
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
More information about the linux-arm-kernel
mailing list