Quoting Arkadiusz Hiler (2017-10-03 12:55:48) > On Fri, Sep 29, 2017 at 03:52:49PM +0000, Patchwork wrote: > > == Series Details == > > > > Series: series starting with [1/7] igt/gem_sync: Sync before starting the clock > > URL : https://patchwork.freedesktop.org/series/31189/ > > State : failure > > > > == Summary == > > > > IGT patchset tested on top of latest successful build > > 09f8cb1a3758fa9868a07b83a3d3db2973d795cc igt/gem_sync: Sync before starting the clock > > > > with latest DRM-Tip kernel build CI_DRM_3157 > > e650b9cdaff6 drm-tip: 2017y-09m-29d-11h-52m-41s UTC integration manifest > > > > Testlist changes: > > +igt@gem_workarounds@basic-read-context > > +igt@gem_workarounds@basic-read-fd > > +igt@gem_workarounds@hibernate-resume > > +igt@gem_workarounds@hibernate-resume-context > > +igt@gem_workarounds@hibernate-resume-fd > > +igt@gem_workarounds@reset-context > > +igt@gem_workarounds@reset-fd > > +igt@gem_workarounds@suspend-resume-context > > +igt@gem_workarounds@suspend-resume-fd > > Shame those haven't got a spin due to gem_sync dmesg-fail. > > > Test chamelium: > > Subgroup hdmi-crc-fast: > > dmesg-warn -> PASS (fi-skl-6700k) fdo#103019 > > Test gem_sync: > > Subgroup basic-all: > > pass -> DMESG-FAIL (fi-blb-e6850) > > pass -> DMESG-FAIL (fi-pnv-d510) > > What's up with those, anyway? Just your irregular GPU stops responding. The stop rings request prior to the GPU reset also failed, so likely the CS parser was stuck or it was exploring an infinite batch or an empty address space. That it affected gem_sync makes me wonder what happened with the duplicate patch I accidentally included. It didn't trigger on my pnv, so just the usual irrational GPU that we wait and see what patterns evolve. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
