Francesco Dolcini <francesco@xxxxxxxxxx> writes:
> On Wed, Oct 26, 2022 at 08:56:04AM +0200, Uwe Kleine-König wrote:
>> On Mon, Oct 03, 2022 at 01:08:50PM +0200, Francesco Dolcini wrote:
>> > recently I have been experiencing an issue with the imx uart on i.MX6ULL
>> > SoC, on the tty console (no flow control, 1152008n1), chars after the 32nd
>> > are lost when typing "fast" (copy/paste or writing to the uart using
>> > automated tools).
>> >
>> > This was tested on Linux 6.0, however it does not look like a brand new
>> > regression, kernel 5.4 was somehow subject to the same issue, although
>> > it was way more difficult to trigger it.
>> >
>> > While I do understand that without flow control this is something that
>> > cannot be prevented, it is pretty fishy that is always the chars after
>> > the 32nd.
>> >
>> > I guess that might be happening is that the FIFO is emptied only by a
>> > timer or when it is full, instead of emptying it when half-full, and the
>> > CPU might not be fast enough leading to an overflow and the chars lost.
>> >
>> > Any idea?
>>
>> It's not unheared that there are bugs in the imx serial driver, but I'm
>> at least half confident that it's not a driver issue.
>>
>> I guess commit 7a637784d517 ("serial: imx: reduce RX interrupt
>> frequency") is relevant, this was added in v5.18-rc1.
>>
>> If this is really the commit that made the issue easier to reproduce,
>> then this is a hint that there is no functional problem and we're "just"
>> talking about irq latency issues. If enabling flow control solves the
>> issue, this is another hint in the same direction.
>
> I can confirm that reverting 7a637784d517 makes the issue more difficult to
> reproduce, and even when it is reproduced the amount of chars lost is
> decreased. Enabling HW flow control is not trivial to test.
>
>> The other side starts sending chars at a high frequency. Once the RX
>> FIFO fill level reaches 8 an irq is triggered. Now if there are 25 more
>> characters received before the irq is serviced you get an overflow and
>> loose chars. Without 7a637784d517 there is a bit more time (i.e. 7
>> character times).
>>
>> So either you use a very high baud rate that is hard to handle (compared
>> to the cpu frequency), or this is a side effect of increased irq
>> latency (which is likely a problem somewhere else).
>
> The uart is configured as 115200 8n1, 86usec per char, given the 25
> chars FIFO is 2.150msec to service the irq and get the data out of the
> fifo.
>
> Just thinking at the MHz the CPU is 792MHz, however it can (and will)
> scale down to 198MHz.
>
> I would say that something like that should be reasonable to handle, but
> it's just my gut feeling ...
A wild guess: make sure you don't use Linux kernel console on serial
port, i.e., /proc/consoles is empty. Serial console may disable
interrupts for very long time intervals due to kernel printk()
implementation.
I've got random data loss on serial ports when turning on and off WiFi
on my board (that caused some printk() diagnostic from the kernel) due
to this deficiency. Took ages to isolate.
-- Sergey Organov
