From owner-freebsd-x11@freebsd.org Sat Apr 27 00:50: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 5F65915A2C62 for ; Sat, 27 Apr 2019 00:50:24 +0000 (UTC) (envelope-from tychon@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EEA368E359 for ; Sat, 27 Apr 2019 00:50:23 +0000 (UTC) (envelope-from tychon@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id B26DA15A2C61; Sat, 27 Apr 2019 00:50:23 +0000 (UTC) Delivered-To: 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 8EC0615A2C60 for ; Sat, 27 Apr 2019 00:50:23 +0000 (UTC) (envelope-from tychon@freebsd.org) Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (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 358A28E355; Sat, 27 Apr 2019 00:50:22 +0000 (UTC) (envelope-from tychon@freebsd.org) Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id AD97E157804; Fri, 26 Apr 2019 20:50:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=sasl; bh= fT3dCd/JrM5Tl3GZE+3nC+JHBMk=; b=NgMNLGjV32OuMy7B5KPn8NxboDYz+/Ty n+qTX+zMbC1AADT93mqUHZomNJxY+nRsiLCQZSS6okMkEROM7ms6gyiYY+YG7FFh h7t7h1yuCBCWAfzP+cN0oXrfmvtHuUBEQAolIZM/nsn7cgzGBPg7GNJj9SophEww 5YDsY3+a4EA= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id A4B72157803; Fri, 26 Apr 2019 20:50:16 -0400 (EDT) Received: from [10.0.1.195] (unknown [146.115.68.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 20067157802; Fri, 26 Apr 2019 20:50:16 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: drm-current-kmod-4.16.g20190424 hangs From: Tycho Nightingale In-Reply-To: Date: Fri, 26 Apr 2019 20:50:15 -0400 Cc: Jakob Alvermark , x11@freebsd.org, kib@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <8F02D757-D8E7-4392-B091-DB00FB9EA185@freebsd.org> References: <5713985b-e97f-c7f2-2592-47a17baf8095@alvermark.net> <88157456-fe57-997a-14f6-9d1b01c2dbc9@alvermark.net> To: Johannes Lundberg X-Mailer: Apple Mail (2.3445.9.1) X-Pobox-Relay-ID: 6C3DCBA6-6886-11E9-B399-DF19F34BB12D-09779102!pb-smtp2.pobox.com X-Rspamd-Queue-Id: 358A28E355 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.95 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.95)[-0.949,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: Sat, 27 Apr 2019 00:50:24 -0000 Hi, > On Apr 26, 2019, at 7:57 PM, Johannes Lundberg = wrote: >=20 > On 4/26/19 4:48 PM, Tycho Nightingale wrote: >> Hi, >>=20 >> There=E2=80=99s not much of a clue in your boot message output. I = understand a recompile is necessary as the underlying linuxkpi data = structure changed; likely breaking module interfaces. This leaves me a = bit concerned about mixing and matching versions of port and kernel. If = you are trying the latest binaries of both compiled with the same = headers and seeing: >>=20 >> device_attach: drmn0 attach returned 19 >>=20 >> It=E2=80=99s that ENODEV where I would start. >=20 > This is because newer kernel requires newer drivers so expected.=20 > drm-current-kmod to 4.16.g20190424 fixes this. So the ENODEV is indicate a binary incompatibility. That makes sense. >> If VT-d is off the recent changes to add bus_dma(9) to LinuxKPI = should be essentially a no-op. Actually ensuring that VT-d is disabled = in your BIOS as it=E2=80=99s been repaired that the Intel GPU and DMAR = are likely incompatible is probably the first thing to try. >>=20 >> Tycho >=20 > Shouldn't it work the same as before bus_dma changes if dmar is = disabled > (which is default)? I think OP hasn't enabled dmar, only updated the > kernel. Before the dma address was the value returned by vtophys(). Now we are = properly going through extra layers but if dmar is fully disabled = busdma_bounce still returns the dma address as the value returned from = vtophys(). My concern seeing an entry for DMAR in the BIOS settings is that somehow = busdma_dmar may somehow be in the picture and the code path followed = isn=E2=80=99t what is expected. Before that opportunity didn=E2=80=99t = exist. Now it does. If busdma_dmar isn=E2=80=99t in the picture it=E2=80=99s not clear to me = how the recent linuxkpi change could be having this effect. I guess the = acid-test is to apply the reverse of the patch and see what happens then = reintroduce the changes to dmapool and dma-mapping independently. > What is the correct way of disabling these changes for only graphics > drivers? I mean, it would be nice if you can use dmar or VT-d for = other > things even if you're running Intel GPU. loader.conf settings of the form hw.busdma.pciD.B.S.F where D is domain, = B is bus, S is slot and F is function can be used to override specific = devices. I don=E2=80=99t believe there is a vendor/device-id and/or = class/sub-class wildcard matching though that would make a nice = addition. If the GPU falls under the purview of another DMAR entity, I=E2=80=99m = also not sure how to enable one while keeping another enabled. Perhaps = kib@, cc:ed knows. Tycho