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 <chris@xxxxxxxxxxxxxxxxxx>
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
> 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
