From owner-freebsd-x11@freebsd.org Mon Apr 29 15:07:09 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 9F5F3159377B for ; Mon, 29 Apr 2019 15:07:09 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.daemonic.se (mail.daemonic.se [176.58.89.161]) (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 D0A5B87B93; Mon, 29 Apr 2019 15:07:08 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from cid.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 44t7Kx4mJ7zDjrs; Mon, 29 Apr 2019 15:07:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mail.daemonic.se ([IPv6:::1]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256) by cid.daemonic.se (mailscanner.daemonic.se [IPv6:::1]) (amavisd-new, port 10587) with ESMTPS id M37eNV5l2keE; Mon, 29 Apr 2019 15:06:59 +0000 (UTC) Received: from garnet.daemonic.se (host-90-236-209-113.mobileonline.telia.com [90.236.209.113]) by mail.daemonic.se (Postfix) with ESMTPSA id 44t7Kv53l8zDjp8; Mon, 29 Apr 2019 15:06:59 +0000 (UTC) Subject: Re: dmar, dma_pool, etc To: Tycho Nightingale , Johannes Lundberg Cc: "freebsd-x11@freebsd.org" References: <9E2356CF-6483-4C06-B4A8-0120088063FE@freebsd.org> From: Niclas Zeising Message-ID: <60b447bb-81da-4c01-e164-bdf10e5560b0@freebsd.org> Date: Mon, 29 Apr 2019 17:06:58 +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: <9E2356CF-6483-4C06-B4A8-0120088063FE@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: D0A5B87B93 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.99)[-0.987,0]; ASN(0.00)[asn:36236, ipnet:176.58.89.0/24, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Mon, 29 Apr 2019 15:07:10 -0000 On 2019-04-29 16:41, Tycho Nightingale wrote: >=20 > Hi, >=20 >> On Apr 27, 2019, at 2:46 PM, Johannes Lundberg w= rote: >> >> Hi >> >> Tycho, I'd like to understand what is the goal with the changes to >> linuxkpi and what you plan to use it for. LinuxKPI base is tightly >> connected to LinuxkPI GPLv2 and the DRM drivers in ports. We need to >> make sure that any change to base LinuxKPI is compatible with what we >> have in ports, or patch the ports to handle the changes in base. >=20 > Understood. The reports of the recent change to LinuxKPI having untowa= rd effects are concerning. I=E2=80=99m trying to get more information to= understand them and at the same time setup a machine in an attempt to re= produce them. >=20 > Stepping back a bit, my addition of bus_dma to LinuxKPI is to make the = mlx4/mlx5 drivers work in an environment where the IOMMU is enabled. Bef= ore physical addresses and dma addresses were not differentiated making t= his impossible. The intention of my patch was to get these devices into = compliance and perhaps also other devices; minimally when the IOMMU is di= sabled things should behave as they were before. How do I disable the IOMMU? >=20 >> For example, there is a CONFIG_INTEL_IOMMU options in Linux code that >> enables DMAR. It turns out, ttm has it's own dma_pool implementation. >> This is possible since in Linux dma_pool is private to dmapool.c. >> Enabling this option for us cause a compile error since dma_pool is >> public in base linuxkpi. I don't know if this is really a problem if >> CONFIG_INTEL_IOMMU (or CONFIG_SWIOTBL) are options that we'll never us= e=E2=80=A6 >=20 > Sounds like there is some redundancy there which can be eliminated. Bu= t with respect to your question of enabling the IOMMU outside of base; th= at=E2=80=99s more than what I intended to. >=20 >> Also, we do have a problem with Firefox causing GPU hangs so I'd >> appreciate it if Tycho could look through linuxkpi_gplv2, drm and >> i915kms (i915kms does not use ttm so no need to look there for problem= s >> with Intel GPU) to see if there are any places needing patching. I kno= w >> there's one vtophys() call in fb_mmap() but IIRC, that is never used. >> I'll look into that next. There are also uses of PHYS_TO_DMAP() and >> VM_PAGE_TO_PHYS(). Would any of these need patching? >> >> Use the default branch at https://github.com/FreeBSDDesktop/kms-drm >=20 > I=E2=80=99m planning to have a look, but to get things working as befor= e nothing further should need patching even if the physical addresses are= treated as dma addresses. >=20 > For the GPU it=E2=80=99s important to note that enabling the IOMMU didn= =E2=80=99t work before, was not a goal of this error, and would be expect= ed to not work right now. However, it=E2=80=99s possible this change rev= ealed some cases where some DMAR functionality was enabled in the BIOS an= d since the support is incomplete breakage is happening. Or something el= se that I am overlooking right now. >=20 Hi! I understand that enabling the IOMMU in the drm drivers is not your=20 priority, which is OK. Since this breaks graphics drivers, however, is it possible to revert=20 the change (and related changes if any) until we figure out what's going=20 on? There are numerous reports of hard lockups or GPU hangs with this=20 change, and it feels like a resolution of the issue is some time off stil= l. As a side note, I can readily reproduce the hang on a spare laptop,=20 please let me know if I can help in testing or diagnosing in any way. Thank you! Regards --=20 Niclas Zeising FreeBSD Graphics Team