[PATCH drm-next] drm/bochs: Add support for drm_panic

[Askar Safin]

 ---- On Wed, 16 Jul 2025 02:00:56 +0400  Jocelyn Falempe <jfalempe at redhat.com> wrote --- 
 > Yes, that's the default if you use a drm driver like bochs with fbdev 

Thank you for answer! I just tried kernel from drm-tip with this config with drm_panic in qemu. And panic works.
But I don't like result.
When drm panic happens, messages printed to /dev/console disappear. Only kernel messages remain.

Here are steps to reproduce. And then I will describe how this breaks my workflow.

Compile kernel from drm-tip ( https://gitlab.freedesktop.org/drm/tip ). I used commit b012f04b5be909a307ff629b297387e0ed55195a .
It seems to include this bochs patch (i. e. "drm/bochs: Add support for drm_panic").
Use this miniconfig:

$ cat mini
CONFIG_64BIT=y

CONFIG_EXPERT=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

CONFIG_DRM_PANIC=y
CONFIG_DRM_PANIC_SCREEN="kmsg"

CONFIG_BLK_DEV_INITRD=y
CONFIG_RD_GZIP=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_SCRIPT=y
$ make KCONFIG_ALLCONFIG=mini allnoconfig

Create initramfs, which contains exactly these files:
$ find /tmp/i -ls
     2861      0 drwxrwxr-x   3 user     user           80 Jul 16 23:56 /tmp/i
     2891      0 drwxrwxr-x   2 user     user           80 Jul 16 23:56 /tmp/i/bin
     2893      0 lrwxrwxrwx   1 user     user            7 Jul 16 23:56 /tmp/i/bin/sh -> busybox
     2892   1980 -rwxr-xr-x   1 user     user      2024544 Jul 16 23:56 /tmp/i/bin/busybox
     2864      4 -rwxrwxr-x   1 user     user           43 Jul 16 23:18 /tmp/i/init

This is "init":
===
#!/bin/sh

set -e

echo hello
sleep 3
exit 0
===

Now boot this in Qemu. I used this command:
$ qemu-system-x86_64 -enable-kvm -m 1024  -kernel arch/x86/boot/bzImage -initrd /tmp/ini.cpio.gz

You will see word "hello", then after 3 seconds the system will fail into drm panic.

What I saw: word "hello" disappeared, when the system falled into panic
What I expected to see: word "hello" should remain.

Now let me describe how this breaks my workflow.

I often use hand-crafted shell scripts as PID 1. Both in Qemu and on real hardware.
I use them to reproduce and bisect various kernel bugs.
I always put "set -e" in the beginning of shell script. This means that script fails after first error.
And thus system fails into kernel panic.
I also sometimes put "set -x" to debug these scripts.
Thus, when script fails and panic happens, then faulty shell command will be last thing printed on screen before panic stacktrace.
But with drm_panic everything printed to /dev/console disappears.
This breaks my workflow.

In Qemu I can easily workaround this by using serial console.

But I cannot do this on real hardware.

And yes, I experience fbcon panic problems on real hardware, too, this is why I'm interested in drm panic: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14658

(I have not yet tested whether drm_panic fixes that fbcon i915 panic problem, but I assume it does.)

I can workaround this by using efi fb with fb panic as opposed to i915. But this will not work if I attempting to catch bug in i915 itself.
(And yes, I recently found another i915-related bug, and I'm trying to debug it using shell scripts running as PID 1.
Here it is: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14598 .)

I can workaround this by logging everything to disk.
But this will not work when everything is mounted read-only.
And this is exactly what happens, when I try to catch that kexec-related bug:
immediately before issuing "kexec -e" command I mount everything read-only.

The only remaining workaround is to redirect everything to /dev/kmsg.
I. e. put "exec > /dev/kmsg 2>&1" to the script.
This will work.
But I still don't like this.

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