[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aCbjN9lqP4ZWV_lY@black.fi.intel.com>
Date: Fri, 16 May 2025 10:03:19 +0300
From: Raag Jadav <raag.jadav@...el.com>
To: André Almeida <andrealmeid@...lia.com>
Cc: Alex Deucher <alexander.deucher@....com>,
Christian König <christian.koenig@....com>,
siqueira@...lia.com, airlied@...il.com, simona@...ll.ch,
rodrigo.vivi@...el.com, jani.nikula@...ux.intel.com,
Xaver Hugl <xaver.hugl@...il.com>,
"Pierre-Loup A . Griffais" <pgriffais@...vesoftware.com>,
Krzysztof Karas <krzysztof.karas@...el.com>,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
kernel-dev@...lia.com, amd-gfx@...ts.freedesktop.org,
intel-xe@...ts.freedesktop.org, intel-gfx@...ts.freedesktop.org
Subject: Re: [PATCH v3 2/3] drm/doc: Add a section about "App information"
for the wedge API
On Mon, May 12, 2025 at 05:34:36PM -0300, André Almeida wrote:
> Add a section about "App information" for the wedge API.
>
> Signed-off-by: André Almeida <andrealmeid@...lia.com>
> ---
> v3:
> - Change "app that caused ..." to "app involved ..."
> - Clarify that devcoredump have more information about what happened
> - Update that PID and APP will be empty if there's no app info
> ---
> Documentation/gpu/drm-uapi.rst | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 69f72e71a96e..3300a928d8ef 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -446,6 +446,23 @@ telemetry information (devcoredump, syslog). This is useful because the first
> hang is usually the most critical one which can result in consequential hangs or
> complete wedging.
>
> +App information
> +---------------
> +
> +The information about which application (if any) was involved in the device
> +wedging is useful for userspace if they want to notify the user about what
> +happened (e.g. the compositor display a message to the user "The <app name>
> +caused a graphical error and the system recovered") or to implement policies
> +(e.g. the daemon may "ban" an app that keeps resetting the device). If the app
> +information is available, the uevent will display as ``PID=<pid>`` and
> +``APP=<task name>``. Otherwise, ``PID`` and ``APP`` will not appear in the event
Personally I'd use Linux specific naming for consistency.
s/APP/TASK
But in any case,
Reviewed-by: Raag Jadav <raag.jadav@...el.com>
> +string.
> +
> +The reliability of this information is driver and hardware specific, and should
> +be taken with a caution regarding it's precision. To have a big picture of what
> +happened,
Nit: what *really* happened
> the devcoredump file provides should have much more detailed
> +information about the device state and about the event.
> +
> Consumer prerequisites
> ----------------------
>
> --
> 2.49.0
>
Powered by blists - more mailing lists