On Tue, Jun 16, 2015 at 04:43:55PM +0100, Tomas Elf wrote: > On 16/06/2015 14:43, Daniel Vetter wrote: > >On Mon, Jun 08, 2015 at 06:03:20PM +0100, Tomas Elf wrote: > >>The TDR ULT used to validate this patch series requires a special uevent for > >>full GPU resets in order to distinguish between different kinds of resets. > >> > >>Signed-off-by: Tomas Elf <tomas.elf@xxxxxxxxx> > > > >Why duplicate the uevent we send out from i915_reset_and_wakeup? At least > >I can't spot what this gets us in addition to the existing one. > >-Daniel > > Look at this line: > >> + reset_event[0] = kasprintf(GFP_KERNEL, "%s", "GPU RESET=0"); > > It doesn't exist in reset_and_wakeup (specifically, the "GPU > RESET=0" part). It's a uevent that happens at the time of the actual > GPU reset (GDRST register write). In the subsequent TDR commit we > add another one to the point of the actual engine reset, which also > includes information about what exact engine was reset. > > The uevents in reset_and_wakeup only tell the user that an error has > been detected and that some kind of reset has happened, these new > uevents specify exactly what kind of reset has happened. This > particular one on its own it's not very meaningful since there is > only one supported form of reset at this point but once we add > engine reset support it's useful to be able to discern the types of > resets from each other (GPU reset, RCS engine reset, VCS engine > reset, VCS2 engine reset, BCS engine reset, VECS engine reset). > > Does that make sense? The ultimate question is how do you envisage these uevents being used? At present, we have abrtd listening out for when to grab the /sys/drm/cardX/error and maybe for GL robustness (though I would imagine if they thought such events useful we would have had demands for a DRM event on the guilty/victim fd). Does it really make sense to send uevents for both hang, partial-reset, and full-reset? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
