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@xxxxxxx>
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@xxxxxxx>
Acked-by: Gerd Hoffmann <kraxel@xxxxxxxxxx>
Link: https://patchwork.freedesktop.org/patch/msgid/20190613073041.29350-2-tzimmermann@xxxxxxx
commit 58540594570778fd149cd8c9b2bff61f2cefa8c9
Author: Thomas Zimmermann <tzimmermann@xxxxxxx>
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@xxxxxxx>
Acked-by: Noralf Trønnes <noralf@xxxxxxxxxxx>
Link: https://patchwork.freedesktop.org/patch/315833/
Signed-off-by: Gerd Hoffmann <kraxel@xxxxxxxxxx>
===
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
