Amdgpu module is references even after unbinding the vtcon
Thomas Zimmermann
tzimmermann at suse.de
Tue Jan 24 16:15:44 UTC 2023
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.
Best regards
Thomas
[1]
https://elixir.bootlin.com/linux/v6.0/source/include/drm/drm_mode_config.h#L890
>
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20230124/2b062417/attachment.sig>
More information about the dri-devel
mailing list