On Tue, Jan 24, 2023 at 11:15 AM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: > > 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. Is that equivalent to setting mode_config.prefer_shadow = 1? If so, we already do that. Alex > > 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
