mirrors/linux-stable
1
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git synced 2024-09-24 11:25:43 +00:00
Code Issues Releases Wiki Activity

drm/todo: Update panic handling todo

Browse source 
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
This commit is contained in:
Daniel Vetter 2022-02-24 14:24:25 +01:00
parent 8c2d9bf5cb
commit 4db3189ce0
1 changed files with 14 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
Documentation/gpu/todo.rst
View file

@ -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
<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
@ -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
<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