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.
