Re: drm-current-kmod-4.16.g20190424 hangs

Hi,

> On Apr 26, 2019, at 7:57 PM, Johannes Lundberg <[email protected]> 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.

>> 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.

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.

> 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.

Tycho

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[email protected]"