Date: Fri, 26 Apr 2019 20:50:15 -0400 From: Tycho Nightingale <tychon@freebsd.org> To: Johannes Lundberg <johalun0@gmail.com> Cc: Jakob Alvermark <jakob@alvermark.net>, x11@freebsd.org, kib@FreeBSD.org Subject: Re: drm-current-kmod-4.16.g20190424 hangs Message-ID: <8F02D757-D8E7-4392-B091-DB00FB9EA185@freebsd.org> In-Reply-To: <e3bc4465-f531-1d43-9103-54cd9d48b757@gmail.com> References: <5713985b-e97f-c7f2-2592-47a17baf8095@alvermark.net> <f8da5a4b-98c9-417f-dd8b-6bd4b4713d25@gmail.com> <88157456-fe57-997a-14f6-9d1b01c2dbc9@alvermark.net> <DD954186-A086-4230-B5C7-3B48640D41F8@freebsd.org> <e3bc4465-f531-1d43-9103-54cd9d48b757@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > On Apr 26, 2019, at 7:57 PM, Johannes Lundberg <johalun0@gmail.com> = 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8F02D757-D8E7-4392-B091-DB00FB9EA185>