F42 Change Proposal: Enable Drm Panic (system-wide)

Project Discussion Change Proposals
,
21

Good question,
Magic system requests output to the kernel messages, so you can see them using dmesg.

So in a VT, you can run dmesg -w, and then press the magic keys, and you should see the output like before.

But I just tested them, and most of them are disabled by default in Fedora, I just get “This sysrq operation is disabled” for l, m, t, p

22

This is again mostly for debugging. I’m not using them in ordinary cases - other than maybe development, but for that I gonna build a custom Kernel anyway - and this is similar to when users disable Plymouth and/or remove quiet from the kernel command line; one can at the same time add sysrq_always_enabled.

When the output becomes compile time disabled, this is gone it seems.

23

Due to the comments about VT_CONSOLE, I spent more time trying to find a better solution, to avoid VT_CONSOLE to overwrite the panic screen.
I submitted a new patch upstream https://patchwork.freedesktop.org/series/136182/, and got good feedback so far, so it’s likely to get merged soon.

It means we won’t need to disable VT_CONSOLE, to enable DRM_PANIC.

I will update the wiki page accordingly, it will make the integration of drm panic much smoother.

Thanks for all you comments!

3 Likes
24

Could this please be reworded like:

As it will crash your machine, you might prefer to do this in a VM (after disabling virtio-gpu, or vmwgfx).

As written it implies that doing it in a VM is possible because it crashes your machine. That’s not the intended meaning, but confused me for a second.

Apart from that little wording quibble, this sounds like a good change.

1 Like
25

It’s no longer necessary to disable VT_CONSOLE to enable DRM_PANIC.
So I have updated the wiki page, and also moved it to self-contained-change, as there are no more system-wide impact by enabling DRM_PANIC.

I’ve also made a new kernel build, with VT_CONSOLE and DRM_PANIC enabled, so you can check by yourself that it works.

https://koji.fedoraproject.org/koji/taskinfo?taskID=120743811

3 Likes
26

This change proposal has now been submitted to FESCo with ticket #3254 for voting.

To find out more, please visit our Changes Policy documentation.

27

I’m no good at ASCII art, but…

    __ 
   |  | _
/ -|O   O|- \
| -|/---\|- |
| -||   ||- |
| -|\---/|- |

The bite is very painful.

28

Wait, does this mean that if the kernel fails before running the first userspace process, I won’t be able to see the console messages no matter what arguments I pass?
If so, that’d be quite bad for debugging such issues…

29

No, now drm_panic works with VT_CONSOLE, so you will still be able to see your boot logs if you want to.
So enabling drm_panic don’t have any impact on boot logs or your fbcon terminal.

Also since then, I’ve implemented drm_log, which should come in linux v6.14
This will allow to show the boot logs using the drm client API, instead of relying on fbdev/vt_console.
drm_log uses the new console API, which means it won’t take the console_lock each time it draws a message on the screen, so it is suitable for RealTime kernel, and it won’t slows down your boot.
https://patchwork.freedesktop.org/series/136789/

3 Likes
30

2 posts were split to a new topic: Use Kdump to handle kernel panics and dumping core to the hard drive to troubleshoot them later? (split from Change Proposal “Enable Drm Panic”)