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 <andrealm...@igalia.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.ja...@intel.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 >
