On 12/02/2026 10:49, Jocelyn Falempe wrote:
On 12/02/2026 00:01, [email protected] wrote:
From: Jocelyn Falempe <[email protected]> Sent: Wednesday, February
11, 2026 1:54 PM
But for this patch, the issue is that drm_panic() never gets called if
CONFIG_PRINTK
isn't set. In that case, kmsg_dump_register() is a stub that returns
an error. So
drm_panic_register() never registers the callback to drm_panic(). And if
drm_panic() isn't going to run, responsibility for doing the VMBus unload
must remain with the VMBus code. It's hard to actually test this case
because
of depending on printk() for debugging output, so double-check my
thinking.
Ok you're right. I changed from
atomic_notifier_chain_register(&panic_notifier_list, ...) to
kmsg_dump_register() in the v10 of drm_panic.
So I should either make DRM_PANIC depends on PRINTK, or call
atomic_notifier_chain_register() if PRINTK is not defined.
As I think kernel without PRINTK are uncommon, I'll probably do the
first solution.
FYI, I just sent the corresponding change:
https://patchwork.freedesktop.org/series/161544/
Best regards,
--
Jocelyn
