Re: [PATCH 0/5] drm: Remove remaining support for kdb

[Thomas Zimmermann <tzimmermann@suse.de>]

Hi

Am 26.11.25 um 13:19 schrieb Daniel Thompson:
> On Tue, Nov 25, 2025 at 07:26:33AM -0800, Doug Anderson wrote:
>> On Tue, Nov 25, 2025 at 5:06 AM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>>> <snip>
>>> Therefore remove the remaining support for kdb from the DRM drivers
>>> and from DRM fbdev emulation. Also remove the hooks from fbdev, as
>>> there are no fbdev drivers with kdb support.
>>>
>>> If we ever want to address kdb support within DRM drivers, a place to
>>> start would be the scanout buffers used by DRM's panic screen. These
>>> use the current display mode. They can be written and flushed without
>>> mode setting involved.
>>>
>>> Note: kdb over serial lines is not affected by this series and continues
>>> to work as before.
>>>
>>> Thomas Zimmermann (5):
>>>    drm/amdgpu: Do not implement mode_set_base_atomic callback
>>>    drm/nouveau: Do not implement mode_set_base_atomic callback
>>>    drm/radeon: Do not implement mode_set_base_atomic callback
>>>    drm/fbdev-helper: Remove drm_fb_helper_debug_enter/_leave()
>>>    fbcon: Remove fb_debug_enter/_leave from struct fb_ops
>> Personally, I've never worked with kdb over anything other than
>> serial, so this won't bother any of my normal workflows. That being
>> said, at least as of a year ago someone on the lists was talking about
>> using kdb with a keyboard and (presumably) a display. You can see a
>> thread here:
>>
>> http://lore.kernel.org/r/20241031192350.GA26688@lichtman.org
>>
>> Daniel may also have comments here?
> TL;DR - I'm pretty relaxed about these changes... but I'd like
>          to know how to test the changes.
>
> Like Doug I only really use kdb via serial but, since I'm maintain
> the thing I do occasionally test kdb works on the qemu console. I don't
> do it very often though because it's a manual test!
>
> I'd assume that will still work since it won't involve any of the
> drivers above. I'm afraid I can't double check that since patch 4
> doesn't apply cleanly in v6.18-rc7 (nor to linux-next... and neither
> does the base-commit appear in linux-next).

To test its effects, ignore this series and simply clear the two 
calbacks at [1]. This is where the debugger invokes fbcon. The series 
removes their implementation in the final patch.

[1] 
https://elixir.bootlin.com/linux/v6.17.9/source/drivers/video/fbdev/core/fbcon.c#L3202

Best regards
Thomas

>
> Anyhow, the only testing I do for kgdboc=kms,kdb is to boot an x86-64
> defconfig+kgdb+kdb kernel in qemu with something like the following
> command line, which FWIW does still work:
>
>      qemu-system-x86_64 -enable-kvm -m 1G -smp 2 \
>        -kernel arch/x86/boot/bzImage \
>        -monitor none -chardev stdio,id=mon,mux=on,signal=off \
>        -serial chardev:mon \
>        -initrd rootfs.cpio.gz \
>        -append " console=tty0 console=ttyS0,115200 kgdboc=kms,kbd,ttyS0 kgdbwait"
>
> The reason I'm fairly relaxed about changes here is that the kbd driver
> only works on PCs with legacy keyboard interfaces. If the kernel is
> talking to the keyboard using USB or I2C (which almost all PCs do) then
> kdb cannot be used anyway.
>
> So... it would be a "cool project"[1] to get kdb running on
> a special interrupt-free I2C mode and with the DRM panic code so you
> can do live analysis if your laptop/chomebook crashes. However it is
> simply not "real enough" to justify slowing down other developers.
>
>
> Daniel.
>
>
> [1] ... but not quite cool enough that I see myself spending time on it
>      though!
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)