On Wed, Oct 26, 2022 at 12:06:34AM -0300, Fabio Estevam wrote: > Hi Francesco, > > On Mon, Oct 3, 2022 at 8:08 AM Francesco Dolcini > <francesco.dolcini@xxxxxxxxxxx> wrote: > > > > Hello all, > > recently I have been experiencing an issue with the imx uart on i.MX6ULL > > Does this also happen with other i.MX devices or only on i.MX6ULL? I do not know for sure, I did not try to actively reproduce the issue on another SoC. On the other hand the issue with the i.MX6ULL was noticed during some testing, and we do exactly the same tests on other SoC and there the issue is either not present or just happening very infrequently. > > 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? > > Can you share a reproducer? Just open the uart console with a terminal application and copy/paste the following: echo -n "12345678901234567890123456789012345678901234567890123456789012345678901234567890" | wc This is supposed to count 80 chars, you'll get less. For doing that minicom is not a good choice since we noticed that it introduces quite some delay between each chars, while using `screen` I am able to reproduce the issue systematically. We initially reproduced the issue using `ser2net` with the exact same test. Francesco
