RE: Amdgpu module is references even after unbinding the vtcon

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[AMD Official Use Only - General]

I would also highly recommend this to be tested with another compositor (Like Weston/Sway etc)

Regards
Shashank
-----Original Message-----
From: Christian König <ckoenig.leichtzumerken@xxxxxxxxx> 
Sent: 26 January 2023 15:12
To: Slivka, Danijel <Danijel.Slivka@xxxxxxx>; Thomas Zimmermann <tzimmermann@xxxxxxx>
Cc: Deucher, Alexander <Alexander.Deucher@xxxxxxx>; dri-devel <dri-devel@xxxxxxxxxxxxxxxxxxxxx>; Sharma, Shashank <Shashank.Sharma@xxxxxxx>
Subject: Re: Amdgpu module is references even after unbinding the vtcon

Hi Danijel,

can you also double check that GDM/X is still capable of acquiring a DMA-buf file descriptor for the buffer (e.g. that we have a DMA-buf handle for it while they are started).

And that handover from fbdev to GDM/X is flicker free?

Thanks,
Christian.

Am 26.01.23 um 14:44 schrieb Slivka, Danijel:
> [AMD Official Use Only - General]
>
> Hi Christian,
>
> I have tested the proposed patch, the issue is not reproducible and everything else seems to work fine.
>
> BR,
> Danijel
>
>> -----Original Message-----
>> From: Christian König <ckoenig.leichtzumerken@xxxxxxxxx>
>> Sent: Thursday, January 26, 2023 1:20 PM
>> To: Slivka, Danijel <Danijel.Slivka@xxxxxxx>; Thomas Zimmermann 
>> <tzimmermann@xxxxxxx>
>> Cc: Deucher, Alexander <Alexander.Deucher@xxxxxxx>; dri-devel <dri- 
>> devel@xxxxxxxxxxxxxxxxxxxxx>; Sharma, Shashank 
>> <Shashank.Sharma@xxxxxxx>
>> Subject: Re: Amdgpu module is references even after unbinding the 
>> vtcon
>>
>> Am 26.01.23 um 10:49 schrieb Slivka, Danijel:
>>> [AMD Official Use Only - General]
>>>
>>> Hi Thomas,
>>>
>>> I have checked what you mentioned.
>>> When loading amdgpu we call  drm_client_init() during fbdev setup 
>>> [1], the
>> refcnt for drm_kms_helper increases from 3 -> 4.
>>> When we unbind vtcon, refcnt for drm_kms_helper drops 4 -> 3, but 
>>> the
>> drm_client_release() [2] is not called.
>>> The drm_client_release() is called only when unloading the amdgpu driver.
>>>
>>> Is this expected?
>> Yes, the client can't be released because it is possible that the 
>> vtcon is bound to this fbdev again.
>>
>> Please test the handle work around I've send around internally. At 
>> least for me that approach seems to work.
>>
>> Regards,
>> Christian.
>>
>>> There is a comment for drm_client_release with regards to fbdev :
>>> * This function should only be called from the unregister callback. An exception
>>>    * is fbdev which cannot free the buffer if userspace has open file descriptors.
>>>
>>> Could this be relevant for our use case, although as 
>>> Application/X/GDM are
>> stopped at that point and no fd should be open.
>>> Thank you,
>>> BR,
>>> Danijel
>>>
>>>> -----Original Message-----
>>>> From: Thomas Zimmermann <tzimmermann@xxxxxxx>
>>>> Sent: Wednesday, January 25, 2023 8:48 PM
>>>> To: Christian König <ckoenig.leichtzumerken@xxxxxxxxx>
>>>> Cc: Deucher, Alexander <Alexander.Deucher@xxxxxxx>; Slivka, Danijel 
>>>> <Danijel.Slivka@xxxxxxx>; dri-devel 
>>>> <dri-devel@xxxxxxxxxxxxxxxxxxxxx>; Sharma, Shashank 
>>>> <Shashank.Sharma@xxxxxxx>
>>>> Subject: Re: Amdgpu module is references even after unbinding the 
>>>> vtcon
>>>>
>>>> Hi Christian
>>>>
>>>> Am 24.01.23 um 15:12 schrieb Christian König:
>>>>> Hi Thomas,
>>>>>
>>>>> we ran into a problem with the general fbcon/fbdev implementation 
>>>>> and though that you might have some idea.
>>>>>
>>>>> What happens is the following:
>>>>> 1. We load amdgpu and get our normal fbcon.
>>>>> 2. fbcon allocates a dump BO as backing store for the console.
>>>>> 3. GDM/X/Applications start, new framebuffers are created BOs 
>>>>> imported, exported etc...
>>>>> 4. Somehow X or GDM iterated over all the framebuffer objects the 
>>>>> kernels knows about and export them as DMA-buf.
>>>>> 5. Application/X/GDM are stopped, handles closed, framebuffers 
>>>>> released etc...
>>>>> 6. We unbind vtcon.
>>>>>
>>>>> At this point the amdgpu module usually has a reference count of 0 
>>>>> and can be unloaded, but since GDM/X/Whoever iterated over all the 
>>>>> known framebuffers and exported them as DMA-buf (for whatever 
>>>>> reason
>>>>> idk) we now still have an exported DMA-buf and with it a reference 
>>>>> to the
>> module.
>>>>> Any idea how we could prevent that?
>>>> Here's another stab in the dark.
>>>>
>>>> The big difference between old-style fbdev and the new one is that 
>>>> the old fbdev setup (e.g., radeon) allocates a GEM object and puts 
>>>> together the fbdev data structures from the BO in a fairly hackish 
>>>> way. The new style uses an in-kernel client with a file to allocate 
>>>> the BO via dumb buffers; and holds a reference to the DRM module.
>>>>
>>>> Maybe the reference comes from the in-kernel DRM client itself. [1] 
>>>> Check if the client resources get released [2] when you unbind vtcon.
>>>>
>>>> Best regards
>>>> Thomas
>>>>
>>>> [1]
>>>> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_
>>>> cl
>>>> ient.c#L87
>>>> [2]
>>>> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_
>>>> cl
>>>> ient.c#L16
>>>> 0
>>>>
>>>>> Thanks,
>>>>> Christian.
>>>> --
>>>> Thomas Zimmermann
>>>> Graphics Driver Developer
>>>> SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, 
>>>> Germany (HRB 36809, AG Nürnberg)
>>>> Geschäftsführer: Ivo Totev




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux