On Thu, Oct 20, 2016 at 10:07:39AM +0100, Chris Wilson wrote:
> For the basic error state, we only desire that an error state be created
> following a hang. For that purpose, we do not need a real hang (slow
> 6-12s) but can inject one instead (fast <1s).
> 
> Signed-off-by: Chris Wilson <[email protected]>

Should we instead speed up hangcheck? I think there's lots of value in
making sure not just error dumping, but also hang detection works somewhat
in BAT. Since if it doesn't any attempt at a full run will lead to pretty
serious disasters. And I have this dream that BAT is the gating thing
deciding whether a patch series deserves a complete pre-merge run ;-)

But since this is a controlled enviromnent we could make hangcheck
super-fast at timing out with some debugfs knob. Would probably also help
a lot with speeding up the gazillion of testcases in gem_reset_stats.
-Daniel

> ---
>  tests/drv_hangman.c | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/drv_hangman.c b/tests/drv_hangman.c
> index 953a4c6..bfe5eaf 100644
> --- a/tests/drv_hangman.c
> +++ b/tests/drv_hangman.c
> @@ -32,6 +32,8 @@
>  #include <sys/stat.h>
>  #include <fcntl.h>
>  
> +#include "igt_debugfs.h"
> +
>  #ifndef I915_PARAM_CMD_PARSER_VERSION
>  #define I915_PARAM_CMD_PARSER_VERSION       28
>  #endif
> @@ -166,15 +168,21 @@ static void test_error_state_basic(void)
>  {
>       int fd;
>  
> -     fd = drm_open_driver(DRIVER_INTEL);
> -
>       clear_error_state();
>       assert_error_state_clear();
>  
> -     submit_hang(fd, I915_EXEC_RENDER);
> +     /* Manually trigger a hang by request a reset */
> +     fd = igt_debugfs_open("i915_wedged", O_WRONLY);
> +     igt_ignore_warn(write(fd, "1\n", 2));
> +     close(fd);
> +
> +     /* Wait for the error capture and gpu reset to complete */
> +     fd = drm_open_driver(DRIVER_INTEL);
> +     gem_quiescent_gpu(fd);
>       close(fd);
>  
>       assert_error_state_collected();
> +
>       clear_error_state();
>       assert_error_state_clear();
>  }
> -- 
> 2.9.3
> 
> _______________________________________________
> Intel-gfx mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to