Re: bochs_hw_init fails to request framebuffer on EFI boot with plymouth visible

["Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1380 bytes --]

On Fri, Jan 17, 2020 at 01:58:25PM +0100, Gerd Hoffmann wrote:
> > Should switching to bochsdrmfb be deferred until efifb gets properly
> > destroyed? How?
> 
> Should be in do_remove_conflicting_framebuffers, everyone might run into
> this.  So lets try wait for all (other) references went away:

Yes, this solves the problem. I guess the proper solution would be to
replace it with some wait queue or such, right?
Is there any guarantee that the process holding /dev/fb0 (plymouthd in
this case) will eventually release it? If not, what could this
(indefinite then) wait cause? Is there any lock held here that could
hang other operations?

> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index d04554959ea7..2d4911cc7ec4 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1726,7 +1726,9 @@ static void do_unregister_framebuffer(struct fb_info *fb_info)
>  	fbcon_fb_unregistered(fb_info);
>  	console_unlock();
>  
> -	/* this may free fb info */
> +	while (atomic_read(&fb_info->count) > 1)
> +		msleep(10);
> +	/* this will free fb info */
>  	put_fb_info(fb_info);
>  }
>  
> 

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 183 bytes --]

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization