Amdgpu module is references even after unbinding the vtcon

Christian König ckoenig.leichtzumerken at gmail.com
Wed Jan 25 06:49:04 UTC 2023


Am 24.01.23 um 17:15 schrieb Thomas Zimmermann:
> Hi
>
> 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?
>
> No real clue, sorry.
>
> But does it change if you use a shadow buffer on top of the amdgpu BO? 
> Set prefer_shadow_fbdev = 1. [1]   I once tried to run generic fbdev 
> without prefer_shadow_fbdev and it never worked. I suspected that some 
> reference counting got wrong, but could never pin it down.  Maybe your 
> issue is similar.
>
> That said, generic fbdev is not so super-optimal for TTM-based 
> drivers. I'm working on improving that, but it's not there yet.

If I'm not completely mistaken this problem is unrelated to TTM and 
could happen with any generic fbdev based driver which supports DMA-buf.

Does VKMS could be used with generic fbdev as well? If yes I think I can 
stitch together a test case demonstrating the issue.

Regards,
Christian.

>
> Best regards
> Thomas
>
>
> [1] 
> https://elixir.bootlin.com/linux/v6.0/source/include/drm/drm_mode_config.h#L890
>
>>
>> Thanks,
>> Christian.
>



More information about the dri-devel mailing list