From: Daniel Vetter Date: Thu, 24 Feb 2022 13:24:25 +0000 (+0100) Subject: drm/todo: Update panic handling todo X-Git-Tag: v6.6.17~3937^2~23^2~2999 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=4db3189ce0621be901f249f8cd8226c977dd601d;p=platform%2Fkernel%2Flinux-rpi.git drm/todo: Update panic handling todo 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 Acked-by: Pekka Paalanen Reviewed-by: Javier Martinez Canillas Cc: Javier Martinez Canillas Cc: Pekka Paalanen Cc: gpiccoli@igalia.com Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220224132425.3463791-1-daniel.vetter@ffwll.ch --- diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 1b2372e..d6a7ebf 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -499,8 +499,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 + `_. * ``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 @@ -512,16 +516,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 + `_. -* 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 + `_ + for some example code that could be reused. Contact: Daniel Vetter