From Fedora Project Wiki
mNo edit summary
 
(6 intermediate revisions by the same user not shown)
Line 8: Line 8:
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. Note that motivation for the change should be in the Benefit to Fedora section below, and this part should answer the question "What?" rather than "Why?". -->
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. Note that motivation for the change should be in the Benefit to Fedora section below, and this part should answer the question "What?" rather than "Why?". -->


Drm_panic is a new feature in the Linux kernel that allows to display a panic screen when a kernel panic occurs.
Drm_panic is a new feature in the Linux kernel that displays a panic screen when a kernel panic occurs. This proposal is to enable DRM_PANIC in the Fedora kernel, to improve the kernel panic user experience.
This proposal is to enable DRM_PANIC in the Fedora kernel, to improve the kernel panic user experience.




Line 17: Line 16:
This should link to your home wiki page so we know who you are.  
This should link to your home wiki page so we know who you are.  
-->
-->
* Name: [[User:jfalempe| Jocelyn Falempe]]
* Name: [[User:jfalempe| Jocelyn Falempe]], [[User:Javierm| Javier Martinez Canillas]]
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
* Email: <jfalempe@redhat.com>
* Email: <jfalempe@redhat.com>, <javierm@redhat.com>
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
-->
-->


== Current status ==
== Current status ==
Line 33: Line 31:


<!-- Select proper category, default is Self Contained Change -->
<!-- Select proper category, default is Self Contained Change -->
[[Category:SelfContainedChange]]
[[Category:SystemWideChange]]
<!-- [[Category:SystemWideChange]] -->


* Targeted release: [https://docs.fedoraproject.org/en-US/releases/f<VERSION>/ Fedora Linux <VERSION>]
* Targeted release: [https://docs.fedoraproject.org/en-US/releases/f<VERSION>/ Fedora Linux <VERSION>]
Line 53: Line 50:
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->


Today, when the linux kernel panics in Fedora, in most cases, the screen just freezes.
When the linux kernel panics in Fedora 40, in most cases, the screen just freezes.
If you're in a VT console, you'll be able to see the kernel debug information, but that is pretty hard to understand for users that are not kernel developers.
If you're in a VT console, you'll be able to see the kernel debug information, but that is pretty hard to understand for users that are not kernel developers.
With this feature, they will see a message saying the computer has crashed, and they need to reboot the computer.
With this feature, they will see a message saying the computer has crashed, and they need to reboot the computer.
Line 60: Line 57:
In order to enable DRM_PANIC, you need to disable VT_CONSOLE in the kernel, this is to prevent a race condition, that if you are in a VT console when the panic occurs, both fbcon and drm_panic will write to the framebuffer at the same time, leading to corrupted output.
In order to enable DRM_PANIC, you need to disable VT_CONSOLE in the kernel, this is to prevent a race condition, that if you are in a VT console when the panic occurs, both fbcon and drm_panic will write to the framebuffer at the same time, leading to corrupted output.
https://patchwork.freedesktop.org/series/134831/
https://patchwork.freedesktop.org/series/134831/
The drawback is that tty0 won't show the kernel kmsg, and it can be harder to debug boot issue. But plymouth already takes care of this, and can display the boot kmsg when no VT console is present. https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/224
The drawback is that tty0 won't show the kernel kmsg, and it can be harder to debug boot issues. But plymouth already takes care of this, and can display the boot kmsg when no VT console is present. https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/224
And the user experience would be better, because plymouth has better font and color support than fbcon.
And the user experience would be better, because plymouth has better font and color support than fbcon.


Line 66: Line 63:
If the driver is not supported, you won't see the panic screen, but it won't be worse than what you have today.
If the driver is not supported, you won't see the panic screen, but it won't be worse than what you have today.


Drm panic provides different panic screen. the default is "user" which will display a simple friendly message telling the user to reboot the computer. But for kernel developer, you can also set it to "kmsg", to see the last kmsg lines (so this is equivalent to the current fbcon).
Drm panic provides different panic screens. The default is "user" which will display a simple friendly message telling the user to reboot the computer. But for kernel developers, you can also set it to "kmsg", to see the last kmsg lines (so this is equivalent to the current fbcon). You can select the panic screen in Kconfig, or as a module parameter (drm.panic_screen=user) or at runtime with "echo -n kmsg > /sys/module/drm/parameters/panic_screen"
You can select the panic screen in Kconfig, or as a module parameter (drm.panic_screen=user) or at runtime with "echo -n kmsg > /sys/module/drm/parameters/panic_screen"


I've also made a proof of concept to add a panic screen with a QR code with debugging information, which will make it easier for users to report kernel panic in Fedora. An example can be seen here:
I've also made a proof of concept to add a panic screen with a QR code with debugging information, which will make it easier for users to report kernel panic in Fedora. An example can be seen here:
Line 108: Line 104:
It's also a first step to switch to userspace console, and being able to disable CONFIG_VT in the kernel.
It's also a first step to switch to userspace console, and being able to disable CONFIG_VT in the kernel.
VT and fbcon are legacy part of the kernel, that would reduce maintenance burden if we can disable them, and
VT and fbcon are legacy part of the kernel, that would reduce maintenance burden if we can disable them, and
It will also reduce CVE impact, as userspace vulnerability are usually less critical.
It will also reduce CVE impact, as userspace vulnerabilities are usually less critical.


== Scope ==
== Scope ==
* Proposal owners:
* Proposal owners:
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
Write documentation on how-to debug boot issues without VT_CONSOLE.
Maybe also change the systemd log configuration, so that it default to writing the log to the console.


* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


* Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
I'm unsure if it has impact on the installer.


* Policies and guidelines: N/A (not needed for this Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: N/A (not needed for this Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Line 129: Line 133:
* Alignment with the Fedora Strategy:  
* Alignment with the Fedora Strategy:  
<!-- Does your proposal align with the current Fedora Strategy: https://discussion.fedoraproject.org/t/fedora-strategy-2028-february-march-planning-work-and-roadmap-til-flock/43618 ? It's okay if it doesn't, but it's something to consider -->
<!-- Does your proposal align with the current Fedora Strategy: https://discussion.fedoraproject.org/t/fedora-strategy-2028-february-march-planning-work-and-roadmap-til-flock/43618 ? It's okay if it doesn't, but it's something to consider -->
I think it perfectly fit the "Fedora is for everyone" goal, as the current kernel panic (either UI freeze or kmsg output in VT) is not user-friendly.


== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==
Line 135: Line 141:
Enabling DRM_PANIC should be transparent to user, but disabling VT_CONSOLE may have a visible impact.
Enabling DRM_PANIC should be transparent to user, but disabling VT_CONSOLE may have a visible impact.
Fortunately since Fedora 40, plymouth is able to display the kmsg messages.
Fortunately since Fedora 40, plymouth is able to display the kmsg messages.
For non-graphical boot, you can use systemd.log_target=console systemd.log_level=info and remove rhgb and quiet to see the kernel boot message.
For non-graphical boot, you can use systemd.log_target=console systemd.log_level=info and remove rhgb and quiet to see the kernel boot message.
But this needs to be documented, and communicated, so that users that debug boot issues, know about this change.


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->

Latest revision as of 16:03, 2 July 2024


Enable Drm Panic

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

Drm_panic is a new feature in the Linux kernel that displays a panic screen when a kernel panic occurs. This proposal is to enable DRM_PANIC in the Fedora kernel, to improve the kernel panic user experience.


Owner

Current status

  • Targeted release: <VERSION>/ Fedora Linux <VERSION>
  • Last updated: 2024-07-02
  • [Announced]
  • [<will be assigned by the Wrangler> Discussion thread]
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

When the linux kernel panics in Fedora 40, in most cases, the screen just freezes. If you're in a VT console, you'll be able to see the kernel debug information, but that is pretty hard to understand for users that are not kernel developers. With this feature, they will see a message saying the computer has crashed, and they need to reboot the computer. Drm_panic has been introduced in kernel v6.10, but is still under active development.

In order to enable DRM_PANIC, you need to disable VT_CONSOLE in the kernel, this is to prevent a race condition, that if you are in a VT console when the panic occurs, both fbcon and drm_panic will write to the framebuffer at the same time, leading to corrupted output. https://patchwork.freedesktop.org/series/134831/ The drawback is that tty0 won't show the kernel kmsg, and it can be harder to debug boot issues. But plymouth already takes care of this, and can display the boot kmsg when no VT console is present. https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/224 And the user experience would be better, because plymouth has better font and color support than fbcon.

Supported drivers are simpledrm, mgag200, ast, (and imx, tidss, on aarch64). I'm working on nouveau support, and I hope i915 and amdgpu will add support too. If the driver is not supported, you won't see the panic screen, but it won't be worse than what you have today.

Drm panic provides different panic screens. The default is "user" which will display a simple friendly message telling the user to reboot the computer. But for kernel developers, you can also set it to "kmsg", to see the last kmsg lines (so this is equivalent to the current fbcon). You can select the panic screen in Kconfig, or as a module parameter (drm.panic_screen=user) or at runtime with "echo -n kmsg > /sys/module/drm/parameters/panic_screen"

I've also made a proof of concept to add a panic screen with a QR code with debugging information, which will make it easier for users to report kernel panic in Fedora. An example can be seen here: https://github.com/kdj0c/panic_report/issues/1

Feedback

Benefit to Fedora

This change will improve the user experience when a kernel panic occurs.

It's also a first step to switch to userspace console, and being able to disable CONFIG_VT in the kernel. VT and fbcon are legacy part of the kernel, that would reduce maintenance burden if we can disable them, and It will also reduce CVE impact, as userspace vulnerabilities are usually less critical.

Scope

  • Proposal owners:

Write documentation on how-to debug boot issues without VT_CONSOLE. Maybe also change the systemd log configuration, so that it default to writing the log to the console.

  • Other developers:



I'm unsure if it has impact on the installer.

  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with the Fedora Strategy:

I think it perfectly fit the "Fedora is for everyone" goal, as the current kernel panic (either UI freeze or kmsg output in VT) is not user-friendly.

Upgrade/compatibility impact

Enabling DRM_PANIC should be transparent to user, but disabling VT_CONSOLE may have a visible impact. Fortunately since Fedora 40, plymouth is able to display the kmsg messages.

For non-graphical boot, you can use systemd.log_target=console systemd.log_level=info and remove rhgb and quiet to see the kernel boot message.

But this needs to be documented, and communicated, so that users that debug boot issues, know about this change.


Early Testing (Optional)

Do you require 'QA Blueprint' support? Y/N

How To Test

Currently the easiest way to test, is to use the simpledrm driver, as it can run on all hardware. So first blacklist your driver (i915, amdgpu or nouveau), and then boot and check that you're using simpledrm. then you can trigger a kernel panic with: echo c > /proc/sysrq-trigger

As it will crash your machine, it's also possible to do this in a VM (so disabling virtio-gpu, or vmwgfx)

Also to check that you can still see the kernel messages at boot, in the grub menu, remove the "quiet" kernel command argument, and you should still see the kernel boot messages on the plymouth screen.


User Experience

Dependencies

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No


Documentation

N/A (not a System Wide Change)

Release Notes