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: 1338 bytes --]

On Wed, Jan 15, 2020 at 03:13:53PM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > > And "grep -A1 0000:00:02.0 /proc/iomem" ?
> > 
> >   c0000000-c0ffffff : 0000:00:02.0
> >   c1000000-c103ffff : 0000:00:04.0
> 
> So no reservation left.  Whatever blocked the pci bar resource (efifb
> probably) is gone now.
> 
> So the interesting question is why that reservation sticked long enough
> to prevent bochs-drm from initializing.  In theory efifb de-init should
> be completed when drm_fb_helper_remove_conflicting_pci_framebuffers()
> returns.

Maybe the fact that switching to text mode plymouth help, gives some
hint?

> Bisecting could help, or springkling printk's into efifb ...

That's a pretty broad range of commits...
I'll try adding some printks.

> > [46921.562805] fbcon: bochs-drmdrmfb (fb0) is primary device
> > [46921.562808] fbcon: Deferring console take-over
> 
> I think that is just some eye candy which delays fbcon init until
> something is actually printed.
> 
> Try "echo hello world > /dev/tty0".
> Maybe tapping enter (to make getty re-print the login prompt) works too.

Oh, yes, indeed it works.

-- 
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