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

[Thorsten Leemhuis]

Hi! Thanks for your report. Given that Thomas' commits that broke things
and then partially made them working again are from 2019 there is no
real benefit in tracking this with regzbot, as it can't be solved with a
revert or such; sure, ideally the involved developers or someone else
will look at it, but often they have much more important things to fix –
and often they moved on to new endeavors and sometimes even retired in
between. Sorry, that's just how it is.

But well, with a bit of luck this mail or something else motivates
someone to look into the issue. :-D Wish you luck!

Ciao, Thorsten

#regzbot introduced: a6c3464f69cf5a8a31e
#regzbot resolve: tracking unpromising

On 10.07.25 06:21, Askar Safin wrote:
> 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
> 
> 
>