All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jocelyn Falempe <jfalempe@redhat.com>
To: "Noralf Trønnes" <noralf@tronnes.org>,
	dri-devel@lists.freedesktop.org, tzimmermann@suse.de,
	airlied@redhat.com, maarten.lankhorst@linux.intel.com,
	mripard@kernel.org, daniel@ffwll.ch, javierm@redhat.com,
	bluescreen_avenger@verizon.net
Subject: Re: [RFC][PATCH v2 0/2] drm/panic: Add a drm panic handler
Date: Tue, 19 Sep 2023 09:40:18 +0200	[thread overview]
Message-ID: <a4941644-1720-ea63-ab07-2589101c17e0@redhat.com> (raw)
In-Reply-To: <5dc52140-e6b1-0fe2-40c3-00dfaa954a03@tronnes.org>

On 19/09/2023 01:19, Noralf Trønnes wrote:
> Hi,
> 
> On 9/15/23 10:28, Jocelyn Falempe wrote:
>> This introduces a new drm panic handler, which displays a message when a panic occurs.
>> So when fbcon is disabled, you can still see a kernel panic.
>>
>> This is one of the missing feature, when disabling VT/fbcon in the kernel:
>> https://www.reddit.com/r/linux/comments/10eccv9/config_vtn_in_2023/
>> Fbcon can be replaced by a userspace kms console, but the panic screen must be done in the kernel.
>>
>> This is a proof of concept, and works only with simpledrm, using a new get_scanout_buffer() api
>>
> 
> There's a panic handling entry in Documentation/gpu/todo.rst pointing to
> some work done in this area.

Thanks a lot for this pointer, I wasn't aware of this previous drm panic 
attempt. I hope this one will go a bit further ;)
Also I wasn't sure about what is allowed or not in the panic handler, 
and this doc makes things really clear.

Regarding the fbcon interactions, I prevent this at build time, I rely 
on userspace consoles, and hope they will progressively replace fbcon.

My real question is how did I missed that ? My google-fu failed me this 
time.

Best regards,

-- 

Jocelyn




> 
> Noralf.
> 
>> To test it, make sure you're using the simpledrm driver, and trigger a panic:
>> echo c > /proc/sysrq-trigger
>>
>> v2
>>   * Use get_scanout_buffer() instead of the drm client API. (Thomas Zimmermann)
>>   * Add the panic reason to the panic message (Nerdopolis)
>>   * Add an exclamation mark (Nerdopolis)
>>   
>> I didn't reuse the fbdev functions yet, that would need some fbdev refactoring, because they rely on struct fb_info, and struct vc_data (for font/console). But I still plan to at least try it for v3.
>>
>> A few more though:
>>   1) what about gpu with multiple monitor connected ?
>> maybe get_scanout_buffer() could return a list of scanout buffers ?
>>   2) I think for some GPU drivers, there might need a flush_scanout_buffer() function, that should be called after the scanout buffer has been filled ?
>>
>> Best regards,
>>
>> Jocelyn Falempe (2):
>>    drm/panic: Add a drm panic handler
>>    drm/simpledrm: Add drm_panic support
>>
>>   drivers/gpu/drm/Kconfig          |  11 ++
>>   drivers/gpu/drm/Makefile         |   1 +
>>   drivers/gpu/drm/drm_drv.c        |   3 +
>>   drivers/gpu/drm/drm_panic.c      | 270 +++++++++++++++++++++++++++++++
>>   drivers/gpu/drm/tiny/simpledrm.c |  17 ++
>>   include/drm/drm_drv.h            |  14 ++
>>   include/drm/drm_panic.h          |  41 +++++
>>   7 files changed, 357 insertions(+)
>>   create mode 100644 drivers/gpu/drm/drm_panic.c
>>   create mode 100644 include/drm/drm_panic.h
>>
>>
>> base-commit: 2dde18cd1d8fac735875f2e4987f11817cc0bc2c
> 


      reply	other threads:[~2023-09-19  7:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-15  8:28 [RFC][PATCH v2 0/2] drm/panic: Add a drm panic handler Jocelyn Falempe
2023-09-15  8:28 ` [PATCH v2 1/2] " Jocelyn Falempe
2023-09-15  8:28 ` [PATCH v2 2/2] drm/simpledrm: Add drm_panic support Jocelyn Falempe
2023-09-16 13:09 ` [RFC][PATCH v2 0/2] drm/panic: Add a drm panic handler nerdopolis
2023-09-18  9:32   ` Jocelyn Falempe
2023-09-18 23:19 ` Noralf Trønnes
2023-09-19  7:40   ` Jocelyn Falempe [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a4941644-1720-ea63-ab07-2589101c17e0@redhat.com \
    --to=jfalempe@redhat.com \
    --cc=airlied@redhat.com \
    --cc=bluescreen_avenger@verizon.net \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=javierm@redhat.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=noralf@tronnes.org \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.