* bochs_hw_init fails to request framebuffer on EFI boot with plymouth visible @ 2020-01-10 16:32 Marek Marczykowski-Górecki 2020-01-13 7:19 ` Gerd Hoffmann 0 siblings, 1 reply; 11+ messages in thread From: Marek Marczykowski-Górecki @ 2020-01-10 16:32 UTC (permalink / raw) To: virtualization [-- 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: bochs_hw_init fails to request framebuffer on EFI boot with plymouth visible 2020-01-10 16:32 bochs_hw_init fails to request framebuffer on EFI boot with plymouth visible Marek Marczykowski-Górecki @ 2020-01-13 7:19 ` Gerd Hoffmann 2020-01-15 0:33 ` Marek Marczykowski-Górecki 0 siblings, 1 reply; 11+ messages in thread From: Gerd Hoffmann @ 2020-01-13 7:19 UTC (permalink / raw) To: Marek Marczykowski-Górecki; +Cc: virtualization 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: bochs_hw_init fails to request framebuffer on EFI boot with plymouth visible 2020-01-13 7:19 ` Gerd Hoffmann @ 2020-01-15 0:33 ` Marek Marczykowski-Górecki [not found] ` <20200115100821.qcdraolkoki6e5tz@sirius.home.kraxel.org> 0 siblings, 1 reply; 11+ messages in thread From: Marek Marczykowski-Górecki @ 2020-01-15 0:33 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: virtualization [-- 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <20200115100821.qcdraolkoki6e5tz@sirius.home.kraxel.org>]
* Re: bochs_hw_init fails to request framebuffer on EFI boot with plymouth visible [not found] ` <20200115100821.qcdraolkoki6e5tz@sirius.home.kraxel.org> @ 2020-01-15 13:41 ` Marek Marczykowski-Górecki 2020-01-15 14:13 ` Gerd Hoffmann 0 siblings, 1 reply; 11+ messages in thread From: Marek Marczykowski-Górecki @ 2020-01-15 13:41 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: virtualization [-- 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: bochs_hw_init fails to request framebuffer on EFI boot with plymouth visible 2020-01-15 13:41 ` Marek Marczykowski-Górecki @ 2020-01-15 14:13 ` Gerd Hoffmann 2020-01-15 14:27 ` Marek Marczykowski-Górecki 0 siblings, 1 reply; 11+ messages in thread From: Gerd Hoffmann @ 2020-01-15 14:13 UTC (permalink / raw) To: Marek Marczykowski-Górecki; +Cc: virtualization 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: bochs_hw_init fails to request framebuffer on EFI boot with plymouth visible 2020-01-15 14:13 ` Gerd Hoffmann @ 2020-01-15 14:27 ` Marek Marczykowski-Górecki 2020-01-15 16:16 ` Gerd Hoffmann 0 siblings, 1 reply; 11+ messages in thread From: Marek Marczykowski-Górecki @ 2020-01-15 14:27 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: virtualization [-- 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: bochs_hw_init fails to request framebuffer on EFI boot with plymouth visible 2020-01-15 14:27 ` Marek Marczykowski-Górecki @ 2020-01-15 16:16 ` Gerd Hoffmann 2020-01-16 2:52 ` Marek Marczykowski-Górecki 0 siblings, 1 reply; 11+ messages in thread From: Gerd Hoffmann @ 2020-01-15 16:16 UTC (permalink / raw) To: Marek Marczykowski-Górecki; +Cc: virtualization 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: bochs_hw_init fails to request framebuffer on EFI boot with plymouth visible 2020-01-15 16:16 ` Gerd Hoffmann @ 2020-01-16 2:52 ` Marek Marczykowski-Górecki 2020-01-17 12:58 ` Gerd Hoffmann 0 siblings, 1 reply; 11+ messages in thread From: Marek Marczykowski-Górecki @ 2020-01-16 2:52 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: virtualization [-- 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: bochs_hw_init fails to request framebuffer on EFI boot with plymouth visible 2020-01-16 2:52 ` Marek Marczykowski-Górecki @ 2020-01-17 12:58 ` Gerd Hoffmann 2020-01-17 15:22 ` Marek Marczykowski-Górecki 0 siblings, 1 reply; 11+ messages in thread From: Gerd Hoffmann @ 2020-01-17 12:58 UTC (permalink / raw) To: Marek Marczykowski-Górecki; +Cc: virtualization > 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); } ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: bochs_hw_init fails to request framebuffer on EFI boot with plymouth visible 2020-01-17 12:58 ` Gerd Hoffmann @ 2020-01-17 15:22 ` Marek Marczykowski-Górecki 2020-01-20 9:58 ` Gerd Hoffmann 0 siblings, 1 reply; 11+ messages in thread From: Marek Marczykowski-Górecki @ 2020-01-17 15:22 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: virtualization [-- 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: bochs_hw_init fails to request framebuffer on EFI boot with plymouth visible 2020-01-17 15:22 ` Marek Marczykowski-Górecki @ 2020-01-20 9:58 ` Gerd Hoffmann 0 siblings, 0 replies; 11+ messages in thread From: Gerd Hoffmann @ 2020-01-20 9:58 UTC (permalink / raw) To: Marek Marczykowski-Górecki; +Cc: virtualization 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-01-20 9:58 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-10 16:32 bochs_hw_init fails to request framebuffer on EFI boot with plymouth visible Marek Marczykowski-Górecki
2020-01-13 7:19 ` Gerd Hoffmann
2020-01-15 0:33 ` Marek Marczykowski-Górecki
[not found] ` <20200115100821.qcdraolkoki6e5tz@sirius.home.kraxel.org>
2020-01-15 13:41 ` Marek Marczykowski-Górecki
2020-01-15 14:13 ` Gerd Hoffmann
2020-01-15 14:27 ` Marek Marczykowski-Górecki
2020-01-15 16:16 ` Gerd Hoffmann
2020-01-16 2:52 ` Marek Marczykowski-Górecki
2020-01-17 12:58 ` Gerd Hoffmann
2020-01-17 15:22 ` Marek Marczykowski-Górecki
2020-01-20 9:58 ` Gerd Hoffmann
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.