Re: rcar_sata DMA warnings on Salvator-X

[Tejun Heo <tj@kernel.org>]

Hello,

On Mon, Feb 29, 2016 at 02:44:16PM +0100, Geert Uytterhoeven wrote:
> sata_rcar ee300000.sata: DMA-API: cpu touching an active dma mapped
> cacheline [cln=0x000000000090ff40]
> ------------[ cut here ]------------
> WARNING: at lib/dma-debug.c:604
> Modules linked in:
> 
> CPU: 2 PID: 329 Comm: udevd Not tainted
...
> [<ffffff8004222b00>] debug_dma_assert_idle+0x180/0x1d0
> [<ffffff800412b0fc>] wp_page_copy.isra.109+0xfc/0x57c
> [<ffffff800412f118>] handle_mm_fault+0x125c/0x1300
> [<ffffff8004092894>] do_page_fault+0x184/0x328
> [<ffffff8004082250>] do_mem_abort+0x40/0x9c

So, somehow udev has mmapped a page which is dma mapped and trying to
falut that in?

> Mapped at:
>  [<ffffff8004220a08>] dma_entry_alloc+0x98/0xac
>  [<ffffff8004222390>] debug_dma_alloc_coherent+0x48/0xe0
>  [<ffffff80042926d8>] dmam_alloc_coherent+0xa8/0xf8
>  [<ffffff80042c77dc>] ata_bmdma_port_start+0x40/0x5c
>  [<ffffff80042b6974>] ata_host_start+0xf8/0x19c

And that region was originally allocated by ata_bmdma_port_start()?
The only thing which gets allocated there is the PRD table which is
the scatter-gather list for the DMA engine and has no reason to be
ever accessed from userland.  Any chance you can find out what udev is
doing at that point?

Thanks.

-- 
tejun