The following reply was made to PR port-arm/54199; it has been noted by GNATS.
From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
To: thorpej%me.com@localhost
Cc: gnats-bugs%netbsd.org@localhost, jmcneill%invisible.ca@localhost, tsutsui%ceres.dti.ne.jp@localhost
Subject: Re: port-arm/54199: arm bus_dmamap_sync assertion failure
Date: Tue, 14 May 2019 22:17:21 +0900
> > I have a question:
> > Is it a valid operation to call bus_dmamap_load(9) and bus_dmamap_sync(9)
> > with dmamap dm_mapsize == 0?
> Anyway, I would say that the API should be tolerant of these situations... If dm_mapsize == 0, then allow offset == 0 and len == 0. If dm_mapsize != 0, still allow len == 0, while enforcing offset invariants.
I see. Thanks for your comment.
(there are several MD code with such assertions)
> Now, the bigger issue I have with this bug is why did sunxi_emac_intr() result in a zero-length bus_dmamap_sync()?
No assertion in PREREAD/PREWRITE but in POST ops after xfers?
With a quick glance, one possible path is failure of
sunxi_emac_setup_rxbuf() in inlined sunxi_emac_rxintr()?
Or, does it still happen even if BUS_DMA_COHERENT is specifed to
bus_dmemem_map(9) for tx/rx descriptor memories?
(i.e. possible race between CPU and DMA on updating descriptors?)