[PATCH v2 1/2] drm: Add GPU reset sysfs event

[Alex Deucher]

On Wed, Mar 16, 2022 at 11:35 AM Rob Clark <robdclark at gmail.com> wrote:
>
> On Wed, Mar 16, 2022 at 7:12 AM Alex Deucher <alexdeucher at gmail.com> wrote:
> >
> > On Wed, Mar 16, 2022 at 4:48 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > >
> [snip]
> > > With new UAPI comes the demand of userspace proof, not hand-waving. You
> > > would not be proposing this new interface if you didn't have use cases
> > > in mind, even just one. You have to document what you imagine the new
> > > thing to be used for, so that the appropriateness can be evaluated. If
> > > the use case is deemed inappropriate for the proposed UAPI, you need to
> > > find another use case to justify adding the new UAPI. If there is no
> > > use for the UAPI, it shouldn't be added, right? Adding UAPI and hoping
> > > someone finds use for it seems backwards to me.
> >
> > We do have a use case.  It's what I described originally.  There is a
> > user space daemon (could be a compositor, could be something else)
> > that runs and listens for GPU reset notifications.  When it receives a
> > notification, it takes action and kills the guilty app and restarts
> > the compositer and gathers any relevant data related to the GPU hang
> > (if possible).  We can revisit this discussion once we have the whole
> > implementation complete.  Other drivers seem to do similar things
> > already today via different means (msm using devcoredump, i915 seems
> > to have its own GPU reset notification mechanism, etc.).  It just
> > seemed like there was value in having a generic drm GPU reset
> > notification, but maybe not yet.
>
> just one point of clarification.. in the msm and i915 case it is
> purely for debugging and telemetry (ie. sending crash logs back to
> distro for analysis if user has crash reporting enabled).. it isn't
> used for triggering any action like killing app or compositor.

Sure.  you could use this proposed event for telemetry gathering as
well.  The important part is the event.  What you do with it is up to
the user.

>
> I would however *strongly* recommend devcoredump support in other GPU
> drivers (i915's thing pre-dates devcoredump by a lot).. I've used it
> to debug and fix a couple obscure issues that I was not able to
> reproduce by myself.

Agreed.  I think devcoredump makes sense and we'll ultimately enable
support for that in amdgpu.  I think there is value in a GPU specific
reset event as well for the use case I outlined, but maybe the
devcoredump one is enough.  We'd just need to rely on the userspace
side to filter as appropriate for events it cares about.  I'm not sure
how many other devcore dump events are commonly seen.

Alex