| Message ID | 1496751646-30358-1-git-send-email-mika.kahola@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Jun 06, 2017 at 03:20:46PM +0300, Mika Kahola wrote: > It has been noticed by our CI BAT testing that in some 1%-3% probability > kms_pipe_crc_basic subtest read-crc-pipe-x-frame-sequence fails when > comparing gathered CRC frames. However, running kms_pipe_crc_basic > subtests alone i.e. outside BAT I was unable to replicate the issue. > > The patch proposes a GPU reset before running the subtests. This way we > can ensure that GPU register settings are reinitialized if they have been > altered by the tests executed earlier in BAT. What does GPU reset have to do with display CRCs? > > The issue has been seen on following bug reports > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99788 > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100367 > > Signed-off-by: Mika Kahola <mika.kahola@intel.com> > --- > tests/kms_pipe_crc_basic.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c > index f49b434..e1940e6 100644 > --- a/tests/kms_pipe_crc_basic.c > +++ b/tests/kms_pipe_crc_basic.c > @@ -175,6 +175,13 @@ static void test_read_crc(data_t *data, int pipe, unsigned flags) > igt_require_f(valid_connectors, "No connector found for pipe %i\n", pipe); > } > > +static void reset_gpu(void) > +{ > + int fd = drm_open_driver(DRIVER_INTEL); > + igt_post_hang_ring(fd, igt_hang_ring(fd, I915_EXEC_DEFAULT)); > + close(fd); > +} > + > data_t data = {0, }; > > igt_main > @@ -194,6 +201,9 @@ igt_main > data.debugfs = igt_debugfs_dir(data.drm_fd); > } > > + /* before running tests, reset gpu */ > + reset_gpu(); > + > igt_subtest("bad-pipe") > test_bad_command(&data, "pipe D none"); > > -- > 2.7.4 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, 2017-06-06 at 15:27 +0300, Ville Syrjälä wrote: > On Tue, Jun 06, 2017 at 03:20:46PM +0300, Mika Kahola wrote: > > > > It has been noticed by our CI BAT testing that in some 1%-3% > > probability > > kms_pipe_crc_basic subtest read-crc-pipe-x-frame-sequence fails > > when > > comparing gathered CRC frames. However, running kms_pipe_crc_basic > > subtests alone i.e. outside BAT I was unable to replicate the > > issue. > > > > The patch proposes a GPU reset before running the subtests. This > > way we > > can ensure that GPU register settings are reinitialized if they > > have been > > altered by the tests executed earlier in BAT. > What does GPU reset have to do with display CRCs? It's unclear but when you do it I was unable to replicate this in couple hundred BAT runs. Maybe the error probability just hits below 1% mark with this. > > > > > > > The issue has been seen on following bug reports > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99788 > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100367 > > > > Signed-off-by: Mika Kahola <mika.kahola@intel.com> > > --- > > tests/kms_pipe_crc_basic.c | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/tests/kms_pipe_crc_basic.c > > b/tests/kms_pipe_crc_basic.c > > index f49b434..e1940e6 100644 > > --- a/tests/kms_pipe_crc_basic.c > > +++ b/tests/kms_pipe_crc_basic.c > > @@ -175,6 +175,13 @@ static void test_read_crc(data_t *data, int > > pipe, unsigned flags) > > igt_require_f(valid_connectors, "No connector found for > > pipe %i\n", pipe); > > } > > > > +static void reset_gpu(void) > > +{ > > + int fd = drm_open_driver(DRIVER_INTEL); > > + igt_post_hang_ring(fd, igt_hang_ring(fd, > > I915_EXEC_DEFAULT)); > > + close(fd); > > +} > > + > > data_t data = {0, }; > > > > igt_main > > @@ -194,6 +201,9 @@ igt_main > > data.debugfs = igt_debugfs_dir(data.drm_fd); > > } > > > > + /* before running tests, reset gpu */ > > + reset_gpu(); > > + > > igt_subtest("bad-pipe") > > test_bad_command(&data, "pipe D none"); > > > > -- > > 2.7.4 > > > > _______________________________________________ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoting Mika Kahola (2017-06-06 13:33:14) > On Tue, 2017-06-06 at 15:27 +0300, Ville Syrjälä wrote: > > On Tue, Jun 06, 2017 at 03:20:46PM +0300, Mika Kahola wrote: > > > > > > It has been noticed by our CI BAT testing that in some 1%-3% > > > probability > > > kms_pipe_crc_basic subtest read-crc-pipe-x-frame-sequence fails > > > when > > > comparing gathered CRC frames. However, running kms_pipe_crc_basic > > > subtests alone i.e. outside BAT I was unable to replicate the > > > issue. > > > > > > The patch proposes a GPU reset before running the subtests. This > > > way we > > > can ensure that GPU register settings are reinitialized if they > > > have been > > > altered by the tests executed earlier in BAT. > > What does GPU reset have to do with display CRCs? > It's unclear but when you do it I was unable to replicate this in > couple hundred BAT runs. Maybe the error probability just hits below 1% > mark with this. So trace through what side-effect the reset may have and find the bug in the kernel. -Chris
On Tue, 2017-06-06 at 14:23 +0100, Chris Wilson wrote: > Quoting Mika Kahola (2017-06-06 13:33:14) > > > > On Tue, 2017-06-06 at 15:27 +0300, Ville Syrjälä wrote: > > > > > > On Tue, Jun 06, 2017 at 03:20:46PM +0300, Mika Kahola wrote: > > > > > > > > > > > > It has been noticed by our CI BAT testing that in some 1%-3% > > > > probability > > > > kms_pipe_crc_basic subtest read-crc-pipe-x-frame-sequence fails > > > > when > > > > comparing gathered CRC frames. However, running > > > > kms_pipe_crc_basic > > > > subtests alone i.e. outside BAT I was unable to replicate the > > > > issue. > > > > > > > > The patch proposes a GPU reset before running the subtests. > > > > This > > > > way we > > > > can ensure that GPU register settings are reinitialized if they > > > > have been > > > > altered by the tests executed earlier in BAT. > > > What does GPU reset have to do with display CRCs? > > It's unclear but when you do it I was unable to replicate this in > > couple hundred BAT runs. Maybe the error probability just hits > > below 1% > > mark with this. > So trace through what side-effect the reset may have and find the bug > in > the kernel. I'm a bit puzzled with this bug. By running the test alone doesn't trigger the issue but this occurs only when running fast-feedback. testlist. Maybe tearing down the previous tests cause some sort of instability which is then triggered when running this test? Any hints or pointers where to look at? > -Chris
Quoting Mika Kahola (2017-06-07 09:00:10) > On Tue, 2017-06-06 at 14:23 +0100, Chris Wilson wrote: > > Quoting Mika Kahola (2017-06-06 13:33:14) > > > > > > On Tue, 2017-06-06 at 15:27 +0300, Ville Syrjälä wrote: > > > > > > > > On Tue, Jun 06, 2017 at 03:20:46PM +0300, Mika Kahola wrote: > > > > > > > > > > > > > > > It has been noticed by our CI BAT testing that in some 1%-3% > > > > > probability > > > > > kms_pipe_crc_basic subtest read-crc-pipe-x-frame-sequence fails > > > > > when > > > > > comparing gathered CRC frames. However, running > > > > > kms_pipe_crc_basic > > > > > subtests alone i.e. outside BAT I was unable to replicate the > > > > > issue. > > > > > > > > > > The patch proposes a GPU reset before running the subtests. > > > > > This > > > > > way we > > > > > can ensure that GPU register settings are reinitialized if they > > > > > have been > > > > > altered by the tests executed earlier in BAT. > > > > What does GPU reset have to do with display CRCs? > > > It's unclear but when you do it I was unable to replicate this in > > > couple hundred BAT runs. Maybe the error probability just hits > > > below 1% > > > mark with this. > > So trace through what side-effect the reset may have and find the bug > > in > > the kernel. > I'm a bit puzzled with this bug. By running the test alone doesn't > trigger the issue but this occurs only when running fast-feedback. > testlist. Maybe tearing down the previous tests cause some sort of > instability which is then triggered when running this test? Any hints > or pointers where to look at? Try forcing a mode change at the start (i.e. -> 1024x768 then back to preferred) and see if that clears up the residual failures. Either way (modeset or gpu reset), dump a snapshot of the registers at the start of a test and after a gpu hang and look at the differences. -Chris
On Wed, 2017-06-07 at 11:24 +0100, Chris Wilson wrote: > Quoting Mika Kahola (2017-06-07 09:00:10) > > > > On Tue, 2017-06-06 at 14:23 +0100, Chris Wilson wrote: > > > > > > Quoting Mika Kahola (2017-06-06 13:33:14) > > > > > > > > > > > > On Tue, 2017-06-06 at 15:27 +0300, Ville Syrjälä wrote: > > > > > > > > > > > > > > > On Tue, Jun 06, 2017 at 03:20:46PM +0300, Mika Kahola wrote: > > > > > > > > > > > > > > > > > > > > > > > > It has been noticed by our CI BAT testing that in some 1%- > > > > > > 3% > > > > > > probability > > > > > > kms_pipe_crc_basic subtest read-crc-pipe-x-frame-sequence > > > > > > fails > > > > > > when > > > > > > comparing gathered CRC frames. However, running > > > > > > kms_pipe_crc_basic > > > > > > subtests alone i.e. outside BAT I was unable to replicate > > > > > > the > > > > > > issue. > > > > > > > > > > > > The patch proposes a GPU reset before running the subtests. > > > > > > This > > > > > > way we > > > > > > can ensure that GPU register settings are reinitialized if > > > > > > they > > > > > > have been > > > > > > altered by the tests executed earlier in BAT. > > > > > What does GPU reset have to do with display CRCs? > > > > It's unclear but when you do it I was unable to replicate this > > > > in > > > > couple hundred BAT runs. Maybe the error probability just hits > > > > below 1% > > > > mark with this. > > > So trace through what side-effect the reset may have and find the > > > bug > > > in > > > the kernel. > > I'm a bit puzzled with this bug. By running the test alone doesn't > > trigger the issue but this occurs only when running fast-feedback. > > testlist. Maybe tearing down the previous tests cause some sort of > > instability which is then triggered when running this test? Any > > hints > > or pointers where to look at? > Try forcing a mode change at the start (i.e. -> 1024x768 then back to > preferred) and see if that clears up the residual failures. Either > way > (modeset or gpu reset), dump a snapshot of the registers at the start > of > a test and after a gpu hang and look at the differences. > -Chris Thanks Chris! I'll try those tricks.
diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c index f49b434..e1940e6 100644 --- a/tests/kms_pipe_crc_basic.c +++ b/tests/kms_pipe_crc_basic.c @@ -175,6 +175,13 @@ static void test_read_crc(data_t *data, int pipe, unsigned flags) igt_require_f(valid_connectors, "No connector found for pipe %i\n", pipe); } +static void reset_gpu(void) +{ + int fd = drm_open_driver(DRIVER_INTEL); + igt_post_hang_ring(fd, igt_hang_ring(fd, I915_EXEC_DEFAULT)); + close(fd); +} + data_t data = {0, }; igt_main @@ -194,6 +201,9 @@ igt_main data.debugfs = igt_debugfs_dir(data.drm_fd); } + /* before running tests, reset gpu */ + reset_gpu(); + igt_subtest("bad-pipe") test_bad_command(&data, "pipe D none");
It has been noticed by our CI BAT testing that in some 1%-3% probability kms_pipe_crc_basic subtest read-crc-pipe-x-frame-sequence fails when comparing gathered CRC frames. However, running kms_pipe_crc_basic subtests alone i.e. outside BAT I was unable to replicate the issue. The patch proposes a GPU reset before running the subtests. This way we can ensure that GPU register settings are reinitialized if they have been altered by the tests executed earlier in BAT. The issue has been seen on following bug reports Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99788 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100367 Signed-off-by: Mika Kahola <mika.kahola@intel.com> --- tests/kms_pipe_crc_basic.c | 10 ++++++++++ 1 file changed, 10 insertions(+)