Stefan Wahren <stefan.wahren@xxxxxxxx> writes: > Hi, > > Am 24.03.23 um 14:37 schrieb Uwe Kleine-König: >> On Fri, Mar 24, 2023 at 09:57:39AM -0300, Fabio Estevam wrote: >>> Hi Stefan, >>> >>> On Fri, Mar 24, 2023 at 8:48 AM Ilpo Järvinen >>> <ilpo.jarvinen@xxxxxxxxxxxxxxx> wrote: >>> >>>> This has come up earlier, see e.g.: >>>> >>>> https://lore.kernel.org/linux-serial/20221003110850.GA28338@xxxxxxxxxxxxxxxxxxxxxxxxxxxx/ >>>> >>>> My somewhat uninformed suggestion: if the overrun problems mostly show up >>>> with console ports, maybe the trigger level could depend on the port >>>> being a console or not? >>> Does the change below help? Taking Ilpo's suggestion into account: >> I wonder if it's a red herring that having the console on that port >> makes a difference. If I understand correctly the problem is pasting >> bigger amounts of data on a ttymxc after having logged in via a getty? >> >> @Stefan: Can you try to reproduce with the port being also a console? > > Sorry, for the confusion. Maybe i should have mentioned that the debug > UART was configured as a console. Chances are that you might experience the same problem that I've described here: https://marc.info/?l=linux-serial&m=158504064609504&w=2 Essentially, any serial console output out of printk() could easily cause 10 milliseconds or even up to 1 second interrupts latency, that will definitely cause overruns on serial ports and gosh knows what other problems. This issue hasn't got any resolution as far as I'm aware. To me it means that I can't use Linux serial console at all on my non-SMP system, unless I remove the offending lock. -- Sergey Organov
