Date: Sat, 27 Apr 2019 12:27:50 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Tycho Nightingale <tychon@freebsd.org> Cc: Johannes Lundberg <johalun0@gmail.com>, Jakob Alvermark <jakob@alvermark.net>, x11@freebsd.org Subject: Re: drm-current-kmod-4.16.g20190424 hangs Message-ID: <20190427092750.GT12936@kib.kiev.ua> In-Reply-To: <8F02D757-D8E7-4392-B091-DB00FB9EA185@freebsd.org> 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> <8F02D757-D8E7-4392-B091-DB00FB9EA185@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 26, 2019 at 08:50:15PM -0400, Tycho Nightingale wrote: > > Hi, > > > On Apr 26, 2019, at 7:57 PM, Johannes Lundberg <johalun0@gmail.com> wrote: > > > > On 4/26/19 4:48 PM, Tycho Nightingale wrote: > >> Hi, > >> > >> There’s 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: > >> > >> device_attach: drmn0 attach returned 19 > >> > >> It’s that ENODEV where I would start. > > > > This is because newer kernel requires newer drivers so expected. > > drm-current-kmod to 4.16.g20190424 fixes this. > > So the ENODEV is indicate a binary incompatibility. That makes sense. Is drmn the driver that I added at drm2 times ? If yes, and your problems starts there, it absolutely has nothing to do with the Linuxkpi changes proper. > > >> 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’s been repaired that the Intel GPU and DMAR are likely incompatible is probably the first thing to try. > >> > >> Tycho > > > > 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’t what is expected. Before that opportunity didn’t exist. Now it does. I do not enable DMAR by default, user must manually turn on the knob to get it acting. Removal of the DMAR ACPI table (this is what typical BIOS knob does) is the sure way guarantee the DMAR inactivation, regardless of system knobs. > > If busdma_dmar isn’t in the picture it’s 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. It is theoretically possible that bounce-dma decides to bounce due to some parameters. E.g. you specified that tag requires single contig segment. But due to the note about drmn above I think it is too unlikely. > > > 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’t 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’m also not sure how to enable one while keeping another enabled. Perhaps kib@, cc:ed knows. > There is no device-id matching, and there is no possibility to enable/disable the specific DMAR units. It is trivial to add id matching, but it sounds strange to me, at least the only use I can see would be the GPU DMAR disable.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190427092750.GT12936>