Some things changed, and add two useful links.
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 --- Documentation/gpu/todo.rst | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 7bf7f2111696..283d35a500bd 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 another. + 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,9 @@ 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. - -* 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. +* 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/`_.
Contact: Daniel Vetter
Hello Daniel,
On 2/24/22 13:59, Daniel Vetter wrote:
Some things changed, and add two useful links.
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
Documentation/gpu/todo.rst | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 7bf7f2111696..283d35a500bd 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 another.
The "over each another" sounds a little bit off, shouldn't be "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,9 @@ 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.
-* 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.
+* 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/`_.
Having these two links in the docs is very useful. Thanks a lot for adding that.
Reviewed-by: Javier Martinez Canillas javierm@redhat.com
Best regards,
Some things changed, and add two useful links.
v2: Also include a link to the QR encoding work. Plus review from Javier.
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 --- 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..2b1e7fa45603 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 preceeding 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
On 24/02/2022 10:24, Daniel Vetter wrote:
Some things changed, and add two useful links.
v2: Also include a link to the QR encoding work. Plus review from Javier.
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
Hi Daniel, thanks for the improvement - much appreciated!
Below a comment inline; other than that, feel free to add my: Reviewed-by: Guilherme G. Piccoli gpiccoli@igalia.com
Cheers,
Guilherme
[...]
-* 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 preceeding dmesg in a QR might help with the
Email client complains about "preceeding" word - misspelled maybe?
- 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
On Thu, Feb 24, 2022 at 10:53:01AM -0300, Guilherme G. Piccoli wrote:
On 24/02/2022 10:24, Daniel Vetter wrote:
Some things changed, and add two useful links.
v2: Also include a link to the QR encoding work. Plus review from Javier.
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
Hi Daniel, thanks for the improvement - much appreciated!
Below a comment inline; other than that, feel free to add my: Reviewed-by: Guilherme G. Piccoli gpiccoli@igalia.com
Cheers,
Guilherme
[...]
-* 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 preceeding dmesg in a QR might help with the
Email client complains about "preceeding" word - misspelled maybe?
Indeed, I've fixed this while applying. -Daniel
- 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
On Thu, 24 Feb 2022 14:24:25 +0100 Daniel Vetter daniel.vetter@ffwll.ch wrote:
Some things changed, and add two useful links.
v2: Also include a link to the QR encoding work. Plus review from Javier.
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
Documentation/gpu/todo.rst | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-)
Acked-by: Pekka Paalanen pekka.paalanen@collabora.com
Thanks, pq
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 7bf7f2111696..2b1e7fa45603 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 preceeding 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
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Daniel Vetter -
Guilherme G. Piccoli -
Javier Martinez Canillas -
Pekka Paalanen