[Intel-gfx] [PATCH i-g-t] tests/gem_reset_stats : mask off ring_stop bits

Gore, Tim tim.gore at intel.com
Wed Jun 3 01:43:03 PDT 2015



> -----Original Message-----
> From: Chris Wilson [mailto:chris at chris-wilson.co.uk]
> Sent: Wednesday, June 03, 2015 9:30 AM
> To: Gore, Tim
> Cc: intel-gfx at lists.freedesktop.org; Wood, Thomas
> Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/gem_reset_stats : mask off
> ring_stop bits
> 
> On Wed, Jun 03, 2015 at 09:20:21AM +0100, tim.gore at intel.com wrote:
> > From: Tim Gore <tim.gore at intel.com>
> >
> > Function check_gpu_ok checks to make sure that any hangs have cleared
> > by testing for (flags == 0). Some tests set the STOP_RINGS_ALLOW_BAN
> > and STOP_RINGS_ALLOW_ERRORS flags but these do not get cleared by an
> > individual ring reset, (a feature added recently to the driver),
> > leading the check_gpu_ok function to think that the gpu is still hung.
> >
> > So I mask the flags with STOP_RING_ALL, to ignore the mode bits and
> > look only at the bits that stop the rings.
> >
> > Once gpu_check_ok sees that the gpu is not hung I write 0 to
> > stop_rings in order to clear it completely. This is because
> > igt_set_stop_rings will only write to stop_rings if either a) they are
> > currently 0 or b) we are writing 0.
> > If we leave the mode bits set then subsequent calls to
> > igt_set_stop_rings to create hangs will fail.
> 
> Can we please just deprecate the stop_rings interface? We can do explicit
> hang injection and GPU resets on gen4+, most of gen3 but not gen2. Even if
> we mask of testing for gen2/3, that still provides (almost, just a couple of
> gen2/3 reset functions will be missed) complete coverage of GEM reset
> handling.
> 
> The benefit is we lose this attrocious interface and remove some hideous
> complications from the kernel.
> -Chris
> 
> --
> Chris Wilson, Intel Open Source Technology Centre

Sounds good to me. I think most people here (Egham) see the stop rings interface as
Being a rather nasty hack, and it certainly makes pain for the TDR mechanism.

  Tim


More information about the Intel-gfx mailing list