bochs_hw_init fails to request framebuffer on EFI boot with plymouth visible

bochs_hw_init fails to request framebuffer on EFI boot with plymouth visible

[Marek Marczykowski-Górecki]

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

Hi,

This is the context of "bochs_drm: failed bochs_hw_init() results in
panic". When I boot the system, if plymouth is visible, it crashes. But
if I press ESC to hide it, it boots fine. bochs_drm is build as module
and _not_ included in the initramfs, so it is loaded only after root
filesystem is mounted. And before that, efifb works just fine, including
nice graphical disk passphrase prompt.

This particular setup is running Xen nested in KVM, but I can reproduce
the crash on plain Linux within KVM too, so that probably doesn't
matter.
Versions:
 - Linux 5.4.5
 - QEMU 4.2.0

Messages about bochs_drm init when it works:

[   33.802504] parport_pc parport_pc.956: Unable to set coherent dma mask: disabling DMA
[   33.873522] MCE: In-kernel MCE decoding enabled.
[   33.899895] parport_pc parport_pc.888: Unable to set coherent dma mask: disabling DMA
[   33.977738] parport_pc parport_pc.632: Unable to set coherent dma mask: disabling DMA
[   34.071587] bochs-drm 0000:00:02.0: remove_conflicting_pci_framebuffers: bar 0: 0xc0000000 -> 0xc0ffffff
[   34.096014] bochs-drm 0000:00:02.0: remove_conflicting_pci_framebuffers: bar 2: 0xc1087000 -> 0xc1087fff
[   34.149109] fb0: switching to bochsdrmfb from EFI VGA
[   34.170491] Console: switching to colour dummy device 80x25
[   34.178497] bochs-drm 0000:00:02.0: vgaarb: deactivate vga console
[   34.188729] [drm] Found bochs VGA, ID 0xb0c5.
[   34.189974] [drm] Framebuffer size 16384 kB @ 0xc0000000, mmio @ 0xc1087000.
[   34.200131] [TTM] Zone  kernel: Available graphics memory: 2004604 KiB
[   34.202006] [TTM] Initializing pool allocator
[   34.233679] [TTM] Initializing DMA pool allocator
[   34.246468] [drm] Found EDID data blob.
[   34.249477] [drm] Initialized bochs-drm 1.0.0 20130925 for 0000:00:02.0 on minor 0
[   34.276315] fbcon: bochs-drmdrmfb (fb0) is primary device
[   34.283968] Console: switching to colour frame buffer device 128x48
[   34.345742] ppdev: user-space parallel port driver
[   34.566261] bochs-drm 0000:00:02.0: fb0: bochs-drmdrmfb frame buffer device


Messages about bochs_drm init when it crashes:

[   32.889058] bochs-drm 0000:00:02.0: remove_conflicting_pci_framebuffers: bar 0: 0xc0000000 -> 0xc0ffffff
[   32.891801] bochs-drm 0000:00:02.0: remove_conflicting_pci_framebuffers: bar 2: 0xc1087000 -> 0xc1087fff
[   32.921205] parport_pc parport_pc.956: Unable to set coherent dma mask: disabling DMA
[   32.927873] parport_pc parport_pc.888: Unable to set coherent dma mask: disabling DMA
[   32.946529] parport_pc parport_pc.632: Unable to set coherent dma mask: disabling DMA
[   32.951345] fb0: switching to bochsdrmfb from EFI VGA
[   32.963031] Console: switching to colour dummy device 80x25
[   32.979805] bochs-drm 0000:00:02.0: vgaarb: deactivate vga console
[   33.015380] MCE: In-kernel MCE decoding enabled.
[   33.030158] bochs-drm 0000:00:02.0: BAR 0: can't reserve [mem 0xc0000000-0xc0ffffff pref]
[   33.032576] [drm:bochs_hw_init [bochs_drm]] *ERROR* Cannot request framebuffer


Full logs: https://gist.github.com/marmarek/ca4fdcfd33d7e5258f15082fafa27bfc

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

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

[Gerd Hoffmann]

On Fri, Jan 10, 2020 at 05:32:11PM +0100, Marek Marczykowski-Górecki wrote:
> Hi,
> 
> This is the context of "bochs_drm: failed bochs_hw_init() results in
> panic". When I boot the system, if plymouth is visible, it crashes. But
> if I press ESC to hide it, it boots fine. bochs_drm is build as module
> and _not_ included in the initramfs, so it is loaded only after root
> filesystem is mounted. And before that, efifb works just fine, including
> nice graphical disk passphrase prompt.

> [   32.951345] fb0: switching to bochsdrmfb from EFI VGA
[ ... ]
> [   33.030158] bochs-drm 0000:00:02.0: BAR 0: can't reserve [mem 0xc0000000-0xc0ffffff pref]

Looks like efifb continues to claim the framebuffer resource
(0xc0000000-0xc0ffffff) for some reason, so bochs-drm can't
reserve it.

No clue why, also doesn't reproduce here (standard fedora 31 5.4.7
kernel).  I don't have an encrypted disk, so no passphrase prompt,
maybe that makes a difference.

How does /proc/iomem look after boot, specifically the 0000:00:02.0 pci
bars?

cheers,
  Gerd

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

[Marek Marczykowski-Górecki]

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

On Mon, Jan 13, 2020 at 08:19:39AM +0100, Gerd Hoffmann wrote:
> On Fri, Jan 10, 2020 at 05:32:11PM +0100, Marek Marczykowski-Górecki wrote:
> > Hi,
> > 
> > This is the context of "bochs_drm: failed bochs_hw_init() results in
> > panic". When I boot the system, if plymouth is visible, it crashes. But
> > if I press ESC to hide it, it boots fine. bochs_drm is build as module
> > and _not_ included in the initramfs, so it is loaded only after root
> > filesystem is mounted. And before that, efifb works just fine, including
> > nice graphical disk passphrase prompt.
> 
> > [   32.951345] fb0: switching to bochsdrmfb from EFI VGA
> [ ... ]
> > [   33.030158] bochs-drm 0000:00:02.0: BAR 0: can't reserve [mem 0xc0000000-0xc0ffffff pref]
> 
> Looks like efifb continues to claim the framebuffer resource
> (0xc0000000-0xc0ffffff) for some reason, so bochs-drm can't
> reserve it.
> 
> No clue why, also doesn't reproduce here (standard fedora 31 5.4.7
> kernel).  I don't have an encrypted disk, so no passphrase prompt,
> maybe that makes a difference.

Extra data point: it worked on 4.19.89.

> How does /proc/iomem look after boot, specifically the 0000:00:02.0 pci
> bars?

grep 0000:00:02.0 /proc/iomem
  c0000000-c0ffffff : 0000:00:02.0
  c1087000-c1087fff : 0000:00:02.0

lspci -vvs 0000:00:02.0
00:02.0 VGA compatible controller: Device 1234:1111 (rev 02) (prog-if 00 [VGA controller])
        Subsystem: Red Hat, Inc. Device 1100
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Region 0: Memory at c0000000 (32-bit, prefetchable) [size=16M]
        Region 2: Memory at c1087000 (32-bit, non-prefetchable) [size=4K]
        Expansion ROM at 000c0000 [disabled] [size=128K]
        Kernel modules: bochs_drm

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

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

[Marek Marczykowski-Górecki]

[-- Attachment #1.1.1: Type: text/plain, Size: 1988 bytes --]

On Wed, Jan 15, 2020 at 11:08:21AM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > > No clue why, also doesn't reproduce here (standard fedora 31 5.4.7
> > > kernel).  I don't have an encrypted disk, so no passphrase prompt,
> > > maybe that makes a difference.
> > 
> > Extra data point: it worked on 4.19.89.
> > 
> > > How does /proc/iomem look after boot, specifically the 0000:00:02.0 pci
> > > bars?
> > 
> > grep 0000:00:02.0 /proc/iomem
> >   c0000000-c0ffffff : 0000:00:02.0
> >   c1087000-c1087fff : 0000:00:02.0
> 
> And "grep -A1 0000:00:02.0 /proc/iomem" ?

  c0000000-c0ffffff : 0000:00:02.0
  c1000000-c103ffff : 0000:00:04.0
--
  c1087000-c1087fff : 0000:00:02.0
  fec00000-fec00fff : Reserved

Full iomem attached.

> Also: what happens if you "rmmod bochs-drm; modprobe bochs-drm"?

Looks promising, but I didn't get my console back:

[46921.550669] bochs-drm 0000:00:02.0: remove_conflicting_pci_framebuffers: bar 0: 0xc0000000 -> 0xc0ffffff
[46921.550673] bochs-drm 0000:00:02.0: remove_conflicting_pci_framebuffers: bar 2: 0xc1087000 -> 0xc1087fff
[46921.550675] bochs-drm 0000:00:02.0: vgaarb: deactivate vga console
[46921.553577] [drm] Found bochs VGA, ID 0xb0c5.
[46921.553579] [drm] Framebuffer size 16384 kB @ 0xc0000000, mmio @ 0xc1087000.
[46921.554733] [TTM] Zone  kernel: Available graphics memory: 1997204 KiB
[46921.554735] [TTM] Initializing pool allocator
[46921.554741] [TTM] Initializing DMA pool allocator
[46921.556460] [drm] Found EDID data blob.
[46921.557129] [drm] Initialized bochs-drm 1.0.0 20130925 for 0000:00:02.0 on minor 0
[46921.562805] fbcon: bochs-drmdrmfb (fb0) is primary device
[46921.562808] fbcon: Deferring console take-over
[46921.562813] bochs-drm 0000:00:02.0: fb0: bochs-drmdrmfb frame buffer device


-- 
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.1.2: iomem.txt --]
[-- Type: text/plain, Size: 1691 bytes --]

00000000-00000fff : Reserved
00001000-0009ffff : System RAM
000a0000-000fffff : Reserved
  000a0000-000bffff : PCI Bus 0000:00
  000f0000-000fffff : System ROM
00100000-007fffff : System RAM
00800000-00807fff : ACPI Non-volatile Storage
00808000-0080ffff : System RAM
00810000-008fffff : ACPI Non-volatile Storage
00900000-be762fff : System RAM
  01000000-01c00e30 : Kernel code
  01c00e31-0263093f : Kernel data
  02c93000-031fffff : Kernel bss
be763000-be774fff : ACPI Non-volatile Storage
be775000-be793fff : Reserved
be794000-be9d5fff : System RAM
be9d6000-beb1afff : Reserved
beb1b000-bfb9afff : System RAM
bfb9b000-bfbf2fff : Reserved
bfbf3000-bfbfafff : ACPI Tables
bfbfb000-bfbfefff : ACPI Non-volatile Storage
bfbff000-bff4ffff : System RAM
bff50000-bff6ffff : Reserved
bff70000-bfffffff : ACPI Non-volatile Storage
c0000000-febfffff : PCI Bus 0000:00
  c0000000-c0ffffff : 0000:00:02.0
  c1000000-c103ffff : 0000:00:04.0
  c1040000-c105ffff : 0000:00:04.0
  c1060000-c107ffff : 0000:00:04.0
  c1080000-c1083fff : 0000:00:04.0
  c1084000-c1084fff : 0000:00:07.0
  c1085000-c1085fff : 0000:00:06.0
  c1086000-c1086fff : 0000:00:05.0
    c1086000-c1086fff : ehci_hcd
  c1087000-c1087fff : 0000:00:02.0
fec00000-fec00fff : Reserved
  fec00000-fec003ff : IOAPIC 0
fed00000-fed003ff : HPET 0
  fed00000-fed003ff : PNP0103:00
fee00000-feefffff : Reserved
  fee00000-fee00fff : Local APIC
100000000-1403e1fff : System RAM
1403e2000-143ffffff : RAM buffer
800000000-87fffffff : PCI Bus 0000:00
  800000000-800003fff : 0000:00:06.0
    800000000-800003fff : virtio-pci-modern
  800004000-800007fff : 0000:00:07.0
    800004000-800007fff : virtio-pci-modern
fd00000000-ffffffffff : Reserved


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

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

[Gerd Hoffmann]

  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

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

[Marek Marczykowski-Górecki]

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

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

[Gerd Hoffmann]

On Wed, Jan 15, 2020 at 03:27:41PM +0100, Marek Marczykowski-Górecki wrote:
> 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?

Maybe plymouth having a /dev/fb0 file handle open in gfx mode has
something to do with it.  But if that is the case I should be able to
reproduce it in theory.  Which is not the case though ...

cheers,
  Gerd

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

[Marek Marczykowski-Górecki]

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

On Wed, Jan 15, 2020 at 05:16:35PM +0100, Gerd Hoffmann wrote:
> On Wed, Jan 15, 2020 at 03:27:41PM +0100, Marek Marczykowski-Górecki wrote:
> > 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?
> 
> Maybe plymouth having a /dev/fb0 file handle open in gfx mode has
> something to do with it.  But if that is the case I should be able to
> reproduce it in theory.  Which is not the case though ...

Yes, looks like plymouthd is holding some file handle open. It may
depend on a specific plymouth configuration, or some timing, I don't
know...
I've added WARN in put_fb_info() (and few more printks) and got output
like the one below. As you can see, first put_fb_info() exit early
(before actual destroy) and only second one (in plymouthd context) do
the destroy - but too late.
Should switching to bochsdrmfb be deferred until efifb gets properly
destroyed? How?

[   29.475736] bochs-drm 0000:00:02.0: remove_conflicting_pci_framebuffers: bar 0: 0xc0000000 -> 0xc0ffffff
[   29.475740] bochs-drm 0000:00:02.0: remove_conflicting_pci_framebuffers: bar 2: 0xc1087000 -> 0xc1087fff
[   29.475743] checking generic (c0000000 1000000) vs hw (c0000000 1000000)
[   29.475745] fb0: switching to bochsdrmfb from EFI VGA
[   29.475828] ------------[ cut here ]------------
[   29.475829] EFI VGA
[   29.475883] WARNING: CPU: 1 PID: 863 at drivers/video/fbdev/core/fbmem.c:77 put_fb_info+0x1a/0x30
[   29.475884] Modules linked in: bochs_drm(+) drm_vram_helper ttm edac_mce_amd pcspkr snd_timer drm_kms_helper snd e1000e soundcore drm i2c_piix4 parport_pc parport xenfs ip_tables dm_thin_pool dm_persistent_data libcrc32c dm_bio_prison dm_crypt ehci_pci serio_raw virtio_console ehci_hcd virtio_scsi ata_generic pata_acpi qemu_fw_cfg floppy xen_privcmd xen_pciback xen_blkback xen_gntalloc xen_gntdev xen_evtchn uinput pkcs8_key_parser
[   29.475901] CPU: 1 PID: 863 Comm: systemd-udevd Tainted: G        W         5.4.5-1.qubes.x86_64+ #4
[   29.475902] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
[   29.475905] RIP: e030:put_fb_info+0x1a/0x30
[   29.475907] Code: 00 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 41 54 4c 8d a7 f0 00 00 00 55 48 89 fd 4c 89 e7 e8 24 41 b6 ff <0f> 0b f0 ff 4d 00 0f 84 ab 23 00 00 e9 d3 23 00 00 0f 1f 44 00 00
[   29.475908] RSP: e02b:ffffc90000d8fa00 EFLAGS: 00010286
[   29.475910] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[   29.475911] RDX: 0000000000000007 RSI: ffffffff82d03247 RDI: 0000000000000200
[   29.475912] RBP: ffff8881360a4800 R08: 00000006dce5772f R09: 0000000000000007
[   29.475913] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8881360a48f0
[   29.475913] R13: ffff888135a62d40 R14: 0000000000000000 R15: 0000000000000001
[   29.475926] FS:  000077896532d940(0000) GS:ffff888140100000(0000) knlGS:0000000000000000
[   29.475927] CS:  e030 DS: 0000 ES: 0000 CR0: 0000000080050033
[   29.475928] CR2: 000075109e9ce008 CR3: 000000013b2e8000 CR4: 0000000000000660
[   29.475931] Call Trace:
[   29.475962]  do_remove_conflicting_framebuffers.cold+0xc2/0x112
[   29.475966]  remove_conflicting_framebuffers+0x30/0xc0
[   29.475968]  remove_conflicting_pci_framebuffers+0xb4/0xe0
[   29.475973]  bochs_pci_probe+0x49/0x160 [bochs_drm]
[   29.475978]  local_pci_probe+0x42/0x80
[   29.475981]  pci_device_probe+0x107/0x1a0
[   29.475985]  really_probe+0x147/0x3c0
[   29.475988]  driver_probe_device+0xb6/0x100
[   29.475991]  device_driver_attach+0x53/0x60
[   29.475993]  __driver_attach+0x8a/0x150
[   29.475995]  ? device_driver_attach+0x60/0x60
[   29.475997]  bus_for_each_dev+0x78/0xc0
[   29.475999]  bus_add_driver+0x14d/0x1f0
[   29.476002]  driver_register+0x6c/0xc0
[   29.476004]  ? 0xffffffffc02cf000
[   29.476008]  do_one_initcall+0x46/0x1f4
[   29.476012]  ? free_unref_page_commit+0x95/0x110
[   29.476016]  ? _cond_resched+0x15/0x30
[   29.476018]  ? kmem_cache_alloc_trace+0x162/0x220
[   29.476021]  ? do_init_module+0x23/0x230
[   29.476023]  do_init_module+0x5c/0x230
[   29.476026]  load_module+0x28c9/0x2b20
[   29.476032]  ? ima_post_read_file+0xf0/0x100
[   29.476034]  ? __do_sys_finit_module+0xaa/0x110
[   29.476036]  __do_sys_finit_module+0xaa/0x110
[   29.476039]  do_syscall_64+0x5b/0x1a0
[   29.476042]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   29.476045] RIP: 0033:0x7789662d31ad
[   29.476047] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab 5c 0c 00 f7 d8 64 89 01 48
[   29.476048] RSP: 002b:00007ffcd6612318 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[   29.476049] RAX: ffffffffffffffda RBX: 00006395e6ee4e90 RCX: 00007789662d31ad
[   29.476050] RDX: 0000000000000000 RSI: 0000778965efa84d RDI: 0000000000000012
[   29.476051] RBP: 0000000000020000 R08: 0000000000000000 R09: 0000000000000007
[   29.476052] R10: 0000000000000012 R11: 0000000000000246 R12: 0000778965efa84d
[   29.476053] R13: 0000000000000000 R14: 00006395e6ef8be0 R15: 00006395e6ee4e90
[   29.476055] ---[ end trace 688bd10d7416ac12 ]---
[   29.476057] put_fb_info: EFI VGA - deferring destroy
[   29.476059] bochs-drm 0000:00:02.0: vgaarb: deactivate vga console
[   29.503578] bochs-drm 0000:00:02.0: BAR 0: can't reserve [mem 0xc0000000-0xc0ffffff pref]
[   29.503586] [drm:bochs_hw_init [bochs_drm]] *ERROR* Cannot request framebuffer
[   29.503629] bochs-drm: probe of 0000:00:02.0 failed with error -16
[   29.802210] ppdev: user-space parallel port driver
[   29.935199] ------------[ cut here ]------------
[   29.935202] EFI VGA
[   29.935290] WARNING: CPU: 1 PID: 357 at drivers/video/fbdev/core/fbmem.c:77 put_fb_info+0x1a/0x30
[   29.935291] Modules linked in: ppdev snd_intel8x0(+) joydev snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm bochs_drm drm_vram_helper ttm edac_mce_amd pcspkr snd_timer drm_kms_helper snd e1000e soundcore drm i2c_piix4 parport_pc parport xenfs ip_tables dm_thin_pool dm_persistent_data libcrc32c dm_bio_prison dm_crypt ehci_pci serio_raw virtio_console ehci_hcd virtio_scsi ata_generic pata_acpi qemu_fw_cfg floppy xen_privcmd xen_pciback xen_blkback xen_gntalloc xen_gntdev xen_evtchn uinput pkcs8_key_parser
[   29.935347] CPU: 1 PID: 357 Comm: plymouthd Tainted: G        W         5.4.5-1.qubes.x86_64+ #4
[   29.935348] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
[   29.935351] RIP: e030:put_fb_info+0x1a/0x30
[   29.935354] Code: 00 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 41 54 4c 8d a7 f0 00 00 00 55 48 89 fd 4c 89 e7 e8 24 41 b6 ff <0f> 0b f0 ff 4d 00 0f 84 ab 23 00 00 e9 d3 23 00 00 0f 1f 44 00 00
[   29.935355] RSP: e02b:ffffc90000ed7e58 EFLAGS: 00010282
[   29.935356] RAX: 0000000000000000 RBX: 00000000000e001f RCX: 0000000000000000
[   29.935357] RDX: 0000000000000007 RSI: ffffffff82d03247 RDI: 0000000000000200
[   29.935358] RBP: ffff8881360a4800 R08: 00000006f846f211 R09: 0000000000000007
[   29.935359] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8881360a48f0
[   29.935376] R13: ffff88813b242fb8 R14: ffff88813625a160 R15: ffff88813a902a80
[   29.935390] FS:  00007857d81d1f00(0000) GS:ffff888140100000(0000) knlGS:0000000000000000
[   29.935391] CS:  e030 DS: 0000 ES: 0000 CR0: 0000000080050033
[   29.935392] CR2: 00006395e6ed0180 CR3: 0000000135b62000 CR4: 0000000000000660
[   29.935412] Call Trace:
[   29.935423]  fb_release+0x57/0x60
[   29.935428]  __fput+0xc1/0x250
[   29.935432]  task_work_run+0x8a/0xb0
[   29.935437]  exit_to_usermode_loop+0x102/0x130
[   29.935440]  do_syscall_64+0x17e/0x1a0
[   29.935444]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   29.935448] RIP: 0033:0x7857d8489c57
[   29.935449] Code: ff ff e8 fc e8 01 00 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 a3 41 f9 ff
[   29.935450] RSP: 002b:00007ffcf4c872b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
[   29.935452] RAX: 0000000000000000 RBX: 000056802e2207d0 RCX: 00007857d8489c57
[   29.935453] RDX: 000056802e221b50 RSI: 0000000000000000 RDI: 000000000000000a
[   29.935453] RBP: 0000000000000000 R08: 0000000000000007 R09: 0000000000000000
[   29.935454] R10: 00007ffcf4c870d4 R11: 0000000000000246 R12: 000056802e221c20
[   29.935455] R13: 000056802e2ae2d0 R14: 0000000000000001 R15: 000056802e222d40
[   29.935457] ---[ end trace 688bd10d7416ac13 ]---
[   29.935459] put_fb_info: EFI VGA - calling destroy
[   29.935460] efifb_destroy
[   29.935461] efifb_destroy: iounmap/memunmap
[   29.939559] efifb_destroy: release_mem_region 0xc0000000-0xc1000000
[   29.939562] Trying to free nonexistent resource <00000000c0000000-00000000c0ffffff>


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

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

[Gerd Hoffmann]

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

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);
 }

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

[Marek Marczykowski-Górecki]

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

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

[Gerd Hoffmann]

On Fri, Jan 17, 2020 at 04:22:11PM +0100, Marek Marczykowski-Górecki wrote:
> 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?

Not sure a wait queue would actually be better.

> Is there any guarantee that the process holding /dev/fb0 (plymouthd in
> this case) will eventually release it?

No.

So it'll probably makes sense to limit the time we are willing to wait
here.

Or maybe take a completely different path and make the reservation
failure in bochs-drm a warning not an error.

cheers,
  Gerd