Re: port-arm/54199: arm bus_dmamap_sync assertion failure

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

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?)
 
 ---
 Izumi Tsutsui