serial: sh-sci: rx overrun errors and hrtimer rx_timeout?

serial: sh-sci: rx overrun errors and hrtimer rx_timeout?

[Dirk Behme]

Hi,

short: What is the sh-sci rx DMA hrtimer configured to rx_timeout good for?

Long story:

Using drivers/tty/serial/sh-sci.c (on 4.14.x Renesas BSP) what is quite 
similar to [1] we got reports about data loss on rx large files (test 
case rx 1GB file):

$ cat /proc/tty/driver/sci
serinfo:1.0 driver revision:
0: uart:scif mmio:0xE6E88000 irq:88 tx:40991 rx:16 RTS|CTS|DTR|DSR|CD
1: uart:hscif mmio:0xE66B0000 irq:45 tx:908 rx:1410 RTS|CTS|DTR|DSR|CD
2: uart:scif mmio:0xE6C40000 irq:89 tx:0 rx:0 CTS|DSR|CD
3: uart:scif mmio:0xE6E68000 irq:87 tx:0 rx:0 CTS|DSR|CD
4: uart:scif mmio:0xE6E60000 irq:86 tx:3506 rx:179863 oe:141 
RTS|CTS|DTR|DSR|CD

See the oe (overrun error?) at uart #4.

For testing the hrtimer rx_timeout was changed (for example to 1000 by 
adding a sysfs interface for it) and with that the oe are reduced 
(again, uart #4):

$ echo 1000 > /sys/class/tty/ttySC4/device/rx_timeout
$ cat /proc/tty/driver/sci
serinfo:1.0 driver revision:
0: uart:scif mmio:0xE6E88000 irq:88 tx:41621 rx:3 RTS|CTS|DTR|DSR|CD
1: uart:hscif mmio:0xE66B0000 irq:45 tx:908 rx:1395 RTS|CTS|DTR|DSR|CD
2: uart:scif mmio:0xE6C40000 irq:89 tx:0 rx:0 CTS|DSR|CD
3: uart:scif mmio:0xE6E68000 irq:87 tx:0 rx:0 CTS|DSR|CD
4: uart:scif mmio:0xE6E60000 irq:86 tx:514 rx:688401 oe:3 RTS|CTS|DTR|DSR|CD

I'm slightly unclear, but general high system load might be involved in 
these tests.

Now, looking at the code, I'm slightly unclear what this hrtimer and its 
timeout is used for in relation to the rx DMA? It seems it controls if 
the DMA is finished after the rx_timeout and if not it setup a new DMA? 
How might changing the timeout influence the overrun errors?

Best regards

Dirk

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/serial/sh-sci.c

Re: serial: sh-sci: rx overrun errors and hrtimer rx_timeout?

[Geert Uytterhoeven]

Hi Dirk,

On Fri, Aug 9, 2024 at 9:27 AM Dirk Behme <dirk.behme@de.bosch.com> wrote:
> short: What is the sh-sci rx DMA hrtimer configured to rx_timeout good for?
>
> Long story:
>
> Using drivers/tty/serial/sh-sci.c (on 4.14.x Renesas BSP) what is quite
> similar to [1] we got reports about data loss on rx large files (test
> case rx 1GB file):

[...]

I'll answer the short question ;-)

When RX DMA is enabled, data is received in the RX FIFO.  Only when
the FIFO is full, an interrupt is raised, and the data is received by
Linux, and passed to the next layer.

So what happens if less data is received than the FIFO size?
In that case, the data would be stuck in the FIFO, as no interrupt
is raised.  Hence a hrtimer is used to make sure Linux receives data
from a partially-filled FIFO when no more data arrives soon (within
rx_timeout µs).

I hope this helps to understand the problem you are seeing.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: serial: sh-sci: rx overrun errors and hrtimer rx_timeout?

[Dirk Behme]

On 19.08.2024 21:26, Geert Uytterhoeven wrote:
> Hi Dirk,
> 
> On Fri, Aug 9, 2024 at 9:27=E2=80=AFAM Dirk Behme <dirk.behme@de.bosch.com>=
>   wrote:
>> short: What is the sh-sci rx DMA hrtimer configured to rx_timeout good fo=
> r?
>>
>> Long story:
>>
>> Using drivers/tty/serial/sh-sci.c (on 4.14.x Renesas BSP) what is quite
>> similar to [1] we got reports about data loss on rx large files (test
>> case rx 1GB file):
> 
> [...]
> 
> I'll answer the short question ;-)
> 
> When RX DMA is enabled, data is received in the RX FIFO.  Only when
> the FIFO is full, an interrupt is raised, and the data is received by
> Linux, and passed to the next layer.
> 
> So what happens if less data is received than the FIFO size?
> In that case, the data would be stuck in the FIFO, as no interrupt
> is raised.  Hence a hrtimer is used to make sure Linux receives data
> from a partially-filled FIFO when no more data arrives soon (within
> rx_timeout =C2=B5s).
> 
> I hope this helps to understand the problem you are seeing.

Yes, many thanks! :)

Just fyi, we are currently investigating two issues we are unsure about:

* It looks like the hrtimer is set to *exactly* the time the data would 
need to fill the DMA buffer (?). So if the hrtimer is started *before* 
the DMA, does the DMA have a chance to finish successfully at all? Need 
to check that with some traces ...

* Due to high system load it seems the hrtimer handler and/or the DMA 
complete callback are delayed. What might explain the overrun errors. 
Need to check this as well ...

Again many thanks for helping,

Dirk