Commit 4db3189c authored by Daniel Vetter's avatar Daniel Vetter
Browse files

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: default avatarGuilherme G. Piccoli <gpiccoli@igalia.com>
Acked-by: default avatarPekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: default avatarJavier 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: default avatarDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220224132425.3463791-1-daniel.vetter@ffwll.ch
parent 8c2d9bf5

Documentation/gpu/todo.rst

+14 −11
Original line number Diff line number Diff line
@@ -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