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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Chris Wilson [mailto:chris@xxxxxxxxxxxxxxxxxx]
> Sent: Wednesday, June 03, 2015 9:30 AM
> To: Gore, Tim
> Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx; Wood, Thomas
> Subject: Re:  [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@xxxxxxxxx wrote:
> > From: Tim Gore <tim.gore@xxxxxxxxx>
> >
> > 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux