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

4 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.

1 Like
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/

4 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”)

31

This change has been deferred to Fedora Linux 43.

To view important dates for the F43 rel;ease, please visit the schedule, and to find out more about how our changes policy works, please visit our docs site.

1 Like