From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: bochs_hw_init fails to request framebuffer on EFI boot with plymouth visible Date: Wed, 15 Jan 2020 15:13:53 +0100 Message-ID: <20200115141353.3kse3uj2mg6ik6k5@sirius.home.kraxel.org> References: <20200110163211.GB29736@mail-itl> <20200113071939.rtqb7yw45zi63fqy@sirius.home.kraxel.org> <20200115003356.GL2507@mail-itl> <20200115100821.qcdraolkoki6e5tz@sirius.home.kraxel.org> <20200115134119.GP1314@mail-itl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20200115134119.GP1314@mail-itl> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" To: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= Cc: virtualization@lists.linux-foundation.org List-Id: virtualization@lists.linuxfoundation.org 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. Bisecting could help, or springkling printk's into efifb ... > [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. cheers, Gerd