On Mon, Aug 14, 2017 at 09:18:35PM +0100, Chris Wilson wrote: > If we tell the machine to reset but they are disallowed, we will leave > the system in a wedged state, preventing the majority of subsequent > tests. > --- > tests/drv_hangman.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/tests/drv_hangman.c b/tests/drv_hangman.c > index 0551ec16..de57e128 100644 > --- a/tests/drv_hangman.c > +++ b/tests/drv_hangman.c > @@ -30,6 +30,7 @@ > #include <limits.h> > #include <sys/types.h> > #include <sys/stat.h> > +#include <sys/ioctl.h> > #include <fcntl.h> > > #include "igt_sysfs.h" > @@ -239,7 +240,9 @@ igt_main > int idx; > > device = drm_open_driver(DRIVER_INTEL); > + igt_allow_hang(device, 0, 0); I think an igt_require_hang_ring here would be better self-documenting. Also, igt_allow/disallow_hang are lacking gtkdocs. What I'm also wondering is where our unexpected hang detection has gone to. In the past we've reported any gpu hang at error level, except when igt indicated it's expected. We seem to have lost that safety net, at least all the unexpected gpu hangs I've recently fixed in igt did not result in dmesg spam. This seems to have happened as part of the big reset rework we've done earlier this year, but I'm not entirely sure. -Daniel > igt_require_gem(device); > + > sysfs = igt_sysfs_open(device, &idx); > igt_assert(sysfs != -1); > } > -- > 2.13.3 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
