Hi Am 10.07.25 um 06:21 schrieb 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 <tzimmerm...@suse.de> Date: Thu Jun 13 09:30:33 2019 +0200 drm/gem-vram: Support pinning buffers to current locationPinning a buffer prevents it from being moved to a different memorylocation. 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 helperSigned-off-by: Thomas Zimmermann <tzimmerm...@suse.de>Acked-by: Gerd Hoffmann <kra...@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190613073041.29350-2-tzimmerm...@suse.de commit 58540594570778fd149cd8c9b2bff61f2cefa8c9 Author: Thomas Zimmermann <tzimmerm...@suse.de> Date: Wed Jul 3 09:58:34 2019 +0200 drm/bochs: Use shadow buffer for bochs framebuffer consoleThe bochs driver (and virtual hardware) requires buffer objects toreside 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 consoleemulation 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_fbdevSigned-off-by: Thomas Zimmermann <tzimmerm...@suse.de>Acked-by: Noralf Trønnes <nor...@tronnes.org> Link: https://patchwork.freedesktop.org/patch/315833/ Signed-off-by: Gerd Hoffmann <kra...@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 bochs driver uses a shadow framebuffer. It's apparently not being flushed to VRAM on kernel panics. You could try the new DRM panic screen to make that happen.
Best regards Thomas
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
-- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
