Hello, Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> writes: > Hello, > > On Sat, Mar 25, 2023 at 12:31:01PM +0100, Stefan Wahren wrote: [...] > > So the current theory that the issue occurs because of a combination of: > > - With a higher watermark value the irq triggers later and so there is > less time the until the ISR must run before an overflow happens; and > > - serial console activity disables irqs for a (relative) long time > > right? > > So on an UP system the problem should occur also on a non-console > port? That's exactly what I've experienced, especially when console baud rate was lower than that of other port(s). I had console at 115200, and got immediate problems on another port working at 460800 whenever relatively lengthy printk output has been emitted (in my case it was info from wlan driver.) > Local irqs are only disabled if some printk is about to be emitted, > isn't it? Yep, and this allows for easy check if it's indeed printk that causes this by eliminating the output using # echo 0 > /proc/sys/kernel/printk > Does this match the error you're seeing? > > That makes me wonder if the error doesn't relate to the UART being a > console port, but the UART being used without DMA?! (So the patch above > fixes the problem for you because on the console port no DMA is used?) Indeed DMA is likely to be able to hide the problem if the cause is printk, though all my results were obtained on DMA-disabled ports, and I never checked with DMA enabled, so unfortunately I have no tested confirmation of this idea. Best regards, -- Sergey Organov
