From 69df20c8b0f0107036398b5f6263bef489d64198 Mon Sep 17 00:00:00 2001
From: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu, 24 Feb 2022 14:24:25 +0100
Subject: drm/todo: Update panic handling todo
Git-commit: 4db3189ce0621be901f249f8cd8226c977dd601d
Patch-mainline: v5.18-rc1
References: jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218 jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225
Some things changed, and add two useful links.
v2: Also include a link to the QR encoding work. Plus review from
Javier.
v3: Fix typo Guilherme spotted.
Reviewed-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: gpiccoli@igalia.com
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220224132425.3463791-1-daniel.vetter@ffwll.ch
Acked-by: Patrik Jakobsson <pjakobsson@suse.de>
---
Documentation/gpu/todo.rst | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 7bf7f2111696..d2dbd8c0cfa1 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -475,8 +475,12 @@ This is a really varied tasks with lots of little bits and pieces:
achieved by using an IPI to the local processor.
* There's a massive confusion of different panic handlers. DRM fbdev emulation
- helpers have one, but on top of that the fbcon code itself also has one. We
- need to make sure that they stop fighting over each another.
+ helpers had their own (long removed), but on top of that the fbcon code itself
+ also has one. We need to make sure that they stop fighting over each other.
+ This is worked around by checking ``oops_in_progress`` at various entry points
+ into the DRM fbdev emulation helpers. A much cleaner approach here would be to
+ switch fbcon to the `threaded printk support
+ <https://lwn.net/Articles/800946/>`_.
* ``drm_can_sleep()`` is a mess. It hides real bugs in normal operations and
isn't a full solution for panic paths. We need to make sure that it only
@@ -488,16 +492,15 @@ This is a really varied tasks with lots of little bits and pieces:
even spinlocks (because NMI and hardirq can panic too). We need to either
make sure to not call such paths, or trylock everything. Really tricky.
-* For the above locking troubles reasons it's pretty much impossible to
- attempt a synchronous modeset from panic handlers. The only thing we could
- try to achive is an atomic ``set_base`` of the primary plane, and hope that
- it shows up. Everything else probably needs to be delayed to some worker or
- something else which happens later on. Otherwise it just kills the box
- harder, prevent the panic from going out on e.g. netconsole.
+* A clean solution would be an entirely separate panic output support in KMS,
+ bypassing the current fbcon support. See `[PATCH v2 0/3] drm: Add panic handling
+ <https://lore.kernel.org/dri-devel/20190311174218.51899-1-noralf@tronnes.org/>`_.
-* There's also proposal for a simplied DRM console instead of the full-blown
- fbcon and DRM fbdev emulation. Any kind of panic handling tricks should
- obviously work for both console, in case we ever get kmslog merged.
+* Encoding the actual oops and preceding dmesg in a QR might help with the
+ dread "important stuff scrolled away" problem. See `[RFC][PATCH] Oops messages
+ transfer using QR codes
+ <https://lore.kernel.org/lkml/1446217392-11981-1-git-send-email-alexandru.murtaza@intel.com/>`_
+ for some example code that could be reused.
Contact: Daniel Vetter
--
2.38.1