[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/guc: fix GuC suspend/resume

Chris Wilson chris at chris-wilson.co.uk
Tue Oct 16 08:49:54 UTC 2018


Quoting Daniele Ceraolo Spurio (2018-10-16 00:43:59)
> 
> 
> On 15/10/18 15:47, Patchwork wrote:
> > == Series Details ==
> > 
> > Series: series starting with [1/2] drm/i915/guc: fix GuC suspend/resume
> > URL   : https://patchwork.freedesktop.org/series/51033/
> > State : failure
> > 
> > == Summary ==
> > 
> > = CI Bug Log - changes from CI_DRM_4984 -> Patchwork_10464 =
> > 
> > == Summary - FAILURE ==
> > 
> >    Serious unknown changes coming with Patchwork_10464 absolutely need to be
> >    verified manually.
> >    
> >    If you think the reported changes have nothing to do with the changes
> >    introduced in Patchwork_10464, please notify your bug team to allow them
> >    to document this new failure mode, which will reduce false positives in CI.
> > 
> >    External URL: https://patchwork.freedesktop.org/api/1.0/series/51033/revisions/1/mbox/
> > 
> > == Possible new issues ==
> > 
> >    Here are the unknown changes that may have been introduced in Patchwork_10464:
> > 
> >    === IGT changes ===
> > 
> >      ==== Possible regressions ====
> > 
> >      igt at drv_selftest@live_execlists:
> >        fi-skl-6700hq:      PASS -> INCOMPLETE
> > 
> 
> Log seem to be cut for this one. Since it is stopping inside 
> live_preempt_smoke it is probably a known issue that Chris mentioned.
> Can't reproduce on my skylake even with the test in a loop.

Yeah, if we have the oops report for that one it might have been
clearer.

> > 
> >      igt at drv_selftest@live_hangcheck:
> >        fi-skl-gvtdvm:      PASS -> DMESG-FAIL
> > 
> 
> <7> [464.966238] [drm:guc_fw_xfer [i915]] GuC status 0x20
> <3> [464.966361] [drm:guc_fw_xfer [i915]] *ERROR* GuC firmware xfer 
> error -110
> 
> This looks like GuC is stuck very early in the boot flow (even before 
> the RSA check). On SKL there are known issues that could cause this and 
> we should reset GuC and retry, but we aren't. Looks like we indirectly 
> stopped applying  WaEnableuKernelHeaderValidFix and 
> WaEnableGuCBootHashCheckNotSet by not returning -EAGAIN from 
> intel_guc_fw_upload in any case. Michal?

That would be useful to fix, as it does fail regularly enough to be a
nuisance.

More importantly, no live_gem failures across the board so the patch does
what it says on the tin. Nice work.
-Chris


More information about the Intel-gfx mailing list