Date: Fri, 29 May 2020 19:22:16 -0700 From: thomas-bsd@skibo.net To: freebsd-arm@freebsd.org Subject: Re: bus_dmamap_load_mbuf_sg failures Message-ID: <b08fe351292501c47ffb007ffe89e0c5@skibo.net> In-Reply-To: <20200524214128.GA3881@piedmont> References: <20200524214128.GA3881@piedmont>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-05-24 14:41, Thomas Skibo wrote: > Hello. > > I just tracked down a bug in a network driver on an arm64 system I am > tinkering with. It seems when bus_dmamap_load_mbuf_sg() fails with > EFBIG > due to too many segments, things are not cleaned up and it causes the > subsequent attempt at bus_dmamap_load_mbuf_sg() with the defragged mbuf > to > fail too (EFBIG again). > > I noticed that in the arm version of busdma_machdep.c, when > _bus_dmamap_load_buffer() fails with EFBIG, it calls > bus_dmamap_unload() on > exit which cleans up the dma map. In the arm64 version of > busdma_bounce.c, > when bounce_bus_dmamap_load_buffer() fails, it does not. Is this a bug > or > are we expected to call bus_dmamap_unload() on a failed > bus_dmamap_load* call? > > I looked around at other architectures and it is inconsistent: arm and > mips > do the unload but x86, arm64, and riscv do not. > > --Thomas > > ===== > Thomas Skibo > thomas-bsd@skibo.net I have filed a bug for this. It seems only arm64 and riscv have this issue. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246852
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b08fe351292501c47ffb007ffe89e0c5>