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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
