Hi, > > open. Which can result in drm driver not being able to grab resources > > (and fail initialization) because the firmware framebuffer still holds > > them. Reportedly plymouth can trigger this. > > Could you please describe issue some more? > > I guess that a problem is happening during DRM driver load while fbdev > driver is loaded? I assume do_unregister_framebuffer() is called inside > do_remove_conflicting_framebuffers()? Yes. Specifically bochs-drm.ko and efifb in virtual machines. > At first glance it seems to be an user-space issue as it should not be > holding references on /dev/fb0 while DRM driver is being loaded. Well, the drm driver is loaded by udev like everything else. Dunno what plymouth (graphical boot screen tool) does to handle the situation. I guess listening to udev events. So it should notice efifb going away and drop the /dev/fb0 reference, but this races against bochs-drm initializing. > > Fix this by trying to wait until all references are gone. Don't wait > > forever though given that userspace might keep the file handle open. > > Where does the 1s maximum delay come from? Pulled out something out of thin air which I expect being on the safe side. plymouth responding on the udev event should need only a small fraction of that. cheers, Gerd _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
