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_client.c#L87 [2] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_client.c#L160
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
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
