[REGRESSION][BISECTED] kernel panic is not displayed correctly in qemu (CONFIG_DRM_BOCHS)

[Askar Safin]

Steps to reproduce:

- Build Linux v6.16-rc5 so:

$ cat mini
CONFIG_64BIT=y

CONFIG_EXPERT=y
CONFIG_EMBEDDED=y

CONFIG_PRINTK=y
CONFIG_PRINTK_TIME=y

CONFIG_PCI=y

CONFIG_TTY=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_DRM=y
CONFIG_DRM_FBDEV_EMULATION=y
CONFIG_DRM_BOCHS=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_PROC_FS=y
$ make KCONFIG_ALLCONFIG=mini allnoconfig
$ make

- Then boot this Linux image in Qemu so:

$ qemu-system-x86_64 -enable-kvm -m 1024 -daemonize -kernel arch/x86_64/boot/bzImage

Kernel will (predictably) panic (because it has no initramfs, nor real disk), but actual panic message will not be shown!

Last shown line is "Run /bin/sh as init process"

My host OS is Debian Trixie. "uname -a":

Linux receipt 6.12.33+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.33-1 (2025-06-19) x86_64 GNU/Linux

Qemu version is:

QEMU emulator version 10.0.2 (Debian 1:10.0.2+ds-1)

Guest kernel is v6.16-rc5 x86_64.

The problem doesn't reproduce on old guest kernels. I. e. old guest kernels actually show panic message.

I did bisect, and bisect showed the following two commits:

===

commit a6c3464f69cf5a8a31eb31cc436e7dbd325b8ff9
Author: Thomas Zimmermann <tzimmermann at suse.de>
Date:   Thu Jun 13 09:30:33 2019 +0200

    drm/gem-vram: Support pinning buffers to current location
    
    Pinning a buffer prevents it from being moved to a different memory
    location. For some operations, such as buffer updates, it is not
    important where the buffer is located. Setting the pin function's
    pl_flag argument to 0 will pin the buffer to whereever it is stored.
    
    v2:
            * document pin flags in PRIME pin helper
    
    Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
    Acked-by: Gerd Hoffmann <kraxel at redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190613073041.29350-2-tzimmermann@suse.de

commit 58540594570778fd149cd8c9b2bff61f2cefa8c9
Author: Thomas Zimmermann <tzimmermann at suse.de>
Date:   Wed Jul 3 09:58:34 2019 +0200

    drm/bochs: Use shadow buffer for bochs framebuffer console
    
    The bochs driver (and virtual hardware) requires buffer objects to
    reside in video ram to display them to the screen. So it can not
    display the framebuffer console because the respective buffer object
    is permanently pinned in system memory.
    
    Using a shadow buffer for the console solves this problem. The console
    emulation will pin the buffer object only during updates from the shadow
    buffer. Otherwise, the bochs driver can freely relocated the buffer
    between system memory and video ram.
    
    v2:
            * select shadow FB via struct drm_mode_config.prefer_shadow_fbdev
    
    Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
    Acked-by: Noralf Trønnes <noralf at tronnes.org>
    Link: https://patchwork.freedesktop.org/patch/315833/
    Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>

===

Commit a6c3464f69cf5a8a31e changed good behavior to absolutely wrong: after a6c3464f69cf5a8a31e I see just black screen.
Then (after many commits) 58540594570778fd149 made screen working again, but now panics are not shown.

So, result: all commits in range a6c3464f69cf5a8a31e .. 58540594570778fd149 are not testable (black screen), all commits before a6c3464f69cf5a8a31e
are "good" (panic is shown) and all commits after 58540594570778fd149 (inclusive) (including v6.16-rc5) are "bad" (panic is not shown).

The next commit after 58540594570778fd149 is 5fd5d2b7c53de5a1290d82, thus correct regzbot instruction is:

#regzbot introduced: a6c3464f69cf5a8a31e..5fd5d2b7c53de5a1290d82

Config above is not special. It is result of minimizing standard Debian config.

The bug is reproducible with standard Debian kernels (if we use them as guests).

Reproduction steps are so:
- Install Debian Trixie to Qemu VM
- Boot it with "init=/bin/true" added (to cause kernel panic)

You will not see panic message.

I minimized this Debian bug to small config shown in the beginning of this letter.

--
Askar Safin
https://types.pl/@safinaskar