Date: Tue, 30 Apr 2019 12:38:17 +0200 From: Niclas Zeising <zeising@freebsd.org> To: Tycho Nightingale <tychon@freebsd.org> Cc: "freebsd-x11@freebsd.org" <freebsd-x11@freebsd.org>, Johannes Lundberg <johalun@FreeBSD.org> Subject: Re: dmar, dma_pool, etc Message-ID: <4a51388c-9802-5ffb-26a5-47236f04dbe9@freebsd.org> In-Reply-To: <C5E9EE94-00F7-4F9D-AFAC-48609F635C8D@freebsd.org> References: <e0415524-3126-5ea2-c2e2-3d3dccc6832e@FreeBSD.org> <9E2356CF-6483-4C06-B4A8-0120088063FE@freebsd.org> <60b447bb-81da-4c01-e164-bdf10e5560b0@freebsd.org> <594E1E71-6834-431E-B122-005E64EDB1C2@freebsd.org> <3a07ffef-a978-2fdd-8d54-85fc0b6f3a63@freebsd.org> <23fe1183-d12c-b4b8-958f-34cee6e33977@freebsd.org> <9E61210C-4939-4D3A-8110-72023B67BBE6@freebsd.org> <C5E9EE94-00F7-4F9D-AFAC-48609F635C8D@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2019-04-30 01:15, Tycho Nightingale wrote: >=20 > Hi, >=20 >> On Apr 29, 2019, at 4:24 PM, Tycho Nightingale <tychon@freebsd.org> wr= ote: >> >> >>> On Apr 29, 2019, at 2:34 PM, Niclas Zeising <zeising@freebsd.org> wro= te: >>> >>> On 2019-04-29 20:27, Niclas Zeising wrote: >>>> On 2019-04-29 18:00, Tycho Nightingale wrote: >>>>>> On Apr 29, 2019, at 11:06 AM, Niclas Zeising <zeising@FreeBSD.org>= wrote: >>>>>> >>>>>> As a side note, I can readily reproduce the hang on a spare laptop= , please let me know if I can help in testing or diagnosing in any way. >>>>> >>>>> >>>>> If you can readily reproduce the hang, since there are 2 halves tha= t comprised the fix (the DMA pool and non-pool mappings) it would be inst= ructive to try reverting either dmapool.h or dma-mapping.h independently = to see if that helps. >>>>> >>>> Hi! >>>> I will test this and report back. Thank you! >>>> Regards >>> >>> Hi! >>> Just reverting dmapool.h or dma-mapping.h doesn't work, it won't buil= d. I need to revert more than that. Can you help me figure out what to r= evert in either case, or provide a patch? >> >> Thanks for trying. I managed to setup my HW and reproduce this and I = see your point that it doesn=E2=80=99t cleave in half perfectly. >> >> Since I=E2=80=99ve got a (non)-working test case, let me investigate a= bit further. >=20 > I believe I=E2=80=99ve figured this out. At least in my case I=E2=80=99= ve been able to eliminate the hangs with the patch included at the bottom= of this email. >=20 > The issue stems from the implementation of dma_map_sg(). According to = the linux DMA documentation[1], entries of the scatter/gather list may be= coalesced: >=20 > int > dma_map_sg(struct device *dev, struct scatterlist *sg, int nents, enum= dma_data_direction direction) >=20 > Returns: the number of DMA address segments mapped (this may be shorte= r > than <nents> passed in if some elements of the scatter/gather list are > physically or virtually adjacent and an IOMMU maps them with a single > entry). >=20 > My implementation of dma_map_sg() does just that. As it turns out ther= e are several consumers of dma_map_sg(), e.g. i915_gem_map_dma_buf() and = i915_gem_gtt_prepare_pages(), and mock_map_dma_buf() among others that ar= en=E2=80=99t compliant with this documented API. Going back to the non-c= oalesced version is likely the only path forward as bugs in the callee re= define this API de facto. Hi! Does this mean that the mentioned functions should be fixed to work with=20 coalesced scatter/gather lists? >=20 > If this addresses the hangs you are seeing, I will post this on Phabric= ator. I'll try the patch, and see what happens. I'll also spread it to others=20 with the same issue, to get more input. Thank you for helping out with this! Regards >=20 > [1] https://www.kernel.org/doc/Documentation/DMA-API.txt >=20 --=20 Niclas Zeising
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4a51388c-9802-5ffb-26a5-47236f04dbe9>