[linux.git drm/ttm]: NULL pointer dereference upon driver probe

Christian König christian.koenig at amd.com
Mon Aug 10 12:20:21 UTC 2020


Am 07.08.20 um 09:02 schrieb Christian König:
> Am 06.08.20 um 20:50 schrieb Roland Scheidegger:
>> Am 06.08.20 um 17:28 schrieb Christian König:
>>> My best guess is that you are facing two separate bugs here.
>>>
>>> Crash #1 is somehow related to CRTCs and might even be cause by the
>>> atomic-helper change you noted below.
>>>
>>> Crash #2 is caused because vmw_bo_create_and_populate() tries to
>>> manually populate a BO object instead of relying on TTM to do it when
>>> necessary. This indeed doesn't work any more because of "drm/ttm: make
>>> TT creation purely optional v3".
>>>
>>> Question is why vmwgfx is doing this?
>> Not really sure unfortunately, it's possible vmwgfx is doing it because
>> ttm lacked some capabilities at some point?
>
> I think so as well, yes.
>
>>   Trying to figure this one out...
>
> Problem is that what vmwgfx is doing here is questionable at best.
>
> By definition BOs in the SYSTEM domain are not accessible by the GPU, 
> even if it is a virtual one.
>
> And what vmwgfx does is allocating one in the SYSTEM domain as not 
> evictable and then bypassing TTM in filling and mapping it to the GPU.
>
> That doesn't really makes sense to me, why shouldn't that BO be put in 
> the GTT domain then in the first place?

Well I think I figured out what VMWGFX is doing here, but you won't like it.

See VMWGFX doesn't support TTMs GTT domain. So to implement the mob and 
otable BOs it is allocating system domain BOs, pinning them and manually 
filling them with pages.

The correct fix would be to audit VMWGFX and fix this handling so that 
it doesn't mess any more with TTM internal object state.

Till that happens we can only revert the patch for now.

Christian.

>
> Christian.
>
>>
>> Roland
>>
>>
>>> Regards,
>>> Christian.



More information about the dri-devel mailing list