From owner-freebsd-x11@freebsd.org Tue Apr 30 10:38:24 2019 Return-Path: Delivered-To: freebsd-x11@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 446EA158C557 for ; Tue, 30 Apr 2019 10:38:24 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2607:f740:d:20::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9F7A768456; Tue, 30 Apr 2019 10:38:23 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from cid.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 44tdKS5x1GzDjs5; Tue, 30 Apr 2019 10:38:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mail.daemonic.se ([127.0.0.1]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256) by cid.daemonic.se (mailscanner.daemonic.se [127.0.0.1]) (amavisd-new, port 10587) with ESMTPS id oATvo0v28JDb; Tue, 30 Apr 2019 10:38:20 +0000 (UTC) Received: from garnet.daemonic.se (host-95-192-79-116.mobileonline.telia.com [95.192.79.116]) by mail.daemonic.se (Postfix) with ESMTPSA id 44tdKR3wh2zDjp8; Tue, 30 Apr 2019 10:38:19 +0000 (UTC) Subject: Re: dmar, dma_pool, etc To: Tycho Nightingale Cc: "freebsd-x11@freebsd.org" , Johannes Lundberg References: <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> From: Niclas Zeising Message-ID: <4a51388c-9802-5ffb-26a5-47236f04dbe9@freebsd.org> Date: Tue, 30 Apr 2019 12:38:17 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 9F7A768456 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.94 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.94)[-0.940,0]; ASN(0.00)[asn:36236, ipnet:2607:f740:d::/48, country:US] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 10:38:24 -0000 On 2019-04-30 01:15, Tycho Nightingale wrote: >=20 > Hi, >=20 >> On Apr 29, 2019, at 4:24 PM, Tycho Nightingale wr= ote: >> >> >>> On Apr 29, 2019, at 2:34 PM, Niclas Zeising 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 = 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 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