linux-kernel - Re: [PATCH v5 0/3] Fix UART DMA freezes for i.MX SOCs

Open Source and information security mailing list archives

Message-ID: <CAHCN7xJL_x1ryOoNW+R2hOZ9dMFem9wni8Uo8QOA3wxpzKLbqQ@mail.gmail.com>
Date:   Mon, 23 Sep 2019 09:55:46 -0500
From:   Adam Ford <aford173@...il.com>
To:     Philipp Puschmann <philipp.puschmann@...ix.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        fugang.duan@....com, jlu@...gutronix.de,
        Fabio Estevam <festevam@...il.com>,
        Sascha Hauer <s.hauer@...gutronix.de>, vkoul@...nel.org,
        NXP Linux Team <linux-imx@....com>,
        Sascha Hauer <kernel@...gutronix.de>,
        dmaengine@...r.kernel.org, dan.j.williams@...el.com,
        Robin Gong <yibin.gong@....com>,
        Shawn Guo <shawnguo@...nel.org>,
        arm-soc <linux-arm-kernel@...ts.infradead.org>,
        Lucas Stach <l.stach@...gutronix.de>
Subject: Re: [PATCH v5 0/3] Fix UART DMA freezes for i.MX SOCs

On Mon, Sep 23, 2019 at 8:58 AM Philipp Puschmann
<philipp.puschmann@...ix.com> wrote:
>
> For some years and since many kernel versions there are reports that
> RX UART DMA channel stops working at one point. So far the usual
> workaround was to disable RX DMA. This patches fix the underlying
> problem.
>
> When a running sdma script does not find any usable destination buffer
> to put its data into it just leads to stopping the channel being
> scheduled again. As solution we manually retrigger the sdma script for
> this channel and by this dissolve the freeze.
>
> While this seems to work fine so far, it may come to buffer overruns
> when the channel - even temporary - is stopped. This case has to be
> addressed by device drivers by increasing the number of DMA periods.
>
> This patch series was tested with the current kernel and backported to
> kernel 4.15 with a special use case using a WL1837MOD via UART and
> provoking the hanging of UART RX DMA within seconds after starting a
> test application. It resulted in well known
>   "Bluetooth: hci0: command 0x0408 tx timeout"
> errors and complete stop of UART data reception. Our Bluetooth traffic
> consists of many independent small packets, mostly only a few bytes,
> causing high usage of periods.
>

Using the 4.19.y branch, this seems to working just fine for me with an i.MX6Q
with WL1837MOD Bluetooth connected to UART2.  I am still seeing some
timeouts with 5.3, but I'm going to continue to run some tests.

Tested-by: Adam Ford <aford173@...il.com> #imx6q w/ 4.19 Kernel

> Signed-off-by: Philipp Puschmann <philipp.puschmann@...ix.com>
> Reviewed-by: Fugang Duan <fugang.duan@....com>
>
> ---
>
> Changelog v5:
>  - join with patch version from Jan Luebbe
>  - adapt comments and patch descriptions
>  - add Reviewed-by
>
> Changelog v4:
>  - fixed the fixes tags
>
> Changelog v3:
>  - fixes typo in dma_wmb
>  - add fixes tags
>
> Changelog v2:
>  - adapt title (this patches are not only for i.MX6)
>  - improve some comments and patch descriptions
>  - add a dma_wb() around BD_DONE flag
>  - add Reviewed-by tags
>  - split off  "serial: imx: adapt rx buffer and dma periods"
>
> Philipp Puschmann (3):
>   dmaengine: imx-sdma: fix buffer ownership
>   dmaengine: imx-sdma: fix dma freezes
>   dmaengine: imx-sdma: drop redundant variable
>
>  drivers/dma/imx-sdma.c | 37 +++++++++++++++++++++++++++----------
>  1 file changed, 27 insertions(+), 10 deletions(-)
>
> --
> 2.23.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives