Hi Francesco, Am Mittwoch, dem 26.10.2022 um 09:32 +0200 schrieb Francesco Dolcini: > 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. > IRQ latency is influenced by lots of things like CPU frequency and idle behavior and the involved drivers on a specific SoC, as they might disable interrupt processing for too long. To test the hypothesis you can enable CONFIG_IRQSOFF_TRACER and then see if you find any smoking gun by running your testcase with this tracer enabled. Regards, Lucas > > > 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 > >
