This may have been fixed 7 runs ago (CI_DRM_4497). Will investigate when I am done filing!

The IGT bug (failing to check if their is a GPU before using it) is still there though. That still affects skl-iommu...

(In reply to Chris Wilson from comment #2)
> The IGT bug (failing to check if their is a GPU before using it) is still
> there though. That still affects skl-iommu...

I guess I should de-dup them then :) Is that the only reason to get a -5?

-5 is from the driver being wedged following an earlier failed reset. In this case that was a driver bug 107259, but for skl-iommu we have a hw feature to contend with. (And in essence iommu will be disabled for skl again in the near future, hopefully before 4.18.)

Until the next time we have a wedged device.

Closing based on the comments above.

(In reply to Chris Wilson from comment #5)
> Until the next time we have a wedged device.

Yeah... It's back... What should we do with this bug?

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_107/fi-cfl-guc/igt@kms_plane_scaling@pipe-c-scaler-with-pixel-format.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_107/fi-cfl-guc/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_107/fi-cfl-guc/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt.html
	
(kms_frontbuffer_tracking:1750) intel_batchbuffer-CRITICAL: Test assertion failure function intel_batchbuffer_flush_on_ring, file ../lib/intel_batchbuffer.c:239:
(kms_frontbuffer_tracking:1750) intel_batchbuffer-CRITICAL: Failed assertion: (drm_intel_gem_bo_context_exec(batch->bo, ctx, used, ring)) == 0
(kms_frontbuffer_tracking:1750) intel_batchbuffer-CRITICAL: Last errno: 5, Input/output error
Subtest fbc-1p-primscrn-cur-indfb-onoff failed.

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_109/fi-kbl-guc/igt@pm_rpm@gem-execbuf-stress-extra-wait.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_109/fi-kbl-guc/igt@pm_rpm@gem-execbuf-stress.html

(pm_rpm:2032) ioctl_wrappers-CRITICAL: Test assertion failure function gem_execbuf, file ../lib/ioctl_wrappers.c:605:
(pm_rpm:2032) ioctl_wrappers-CRITICAL: Failed assertion: __gem_execbuf(fd, execbuf) == 0
(pm_rpm:2032) ioctl_wrappers-CRITICAL: error: -5 != 0
Subtest gem-execbuf-stress failed.

(In reply to Martin Peres from comment #8)
> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_109/fi-kbl-guc/
> igt@pm_rpm@gem-execbuf-stress-extra-wait.html
> 
> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_109/fi-kbl-guc/
> igt@pm_rpm@gem-execbuf-stress.html
> 
> (pm_rpm:2032) ioctl_wrappers-CRITICAL: Test assertion failure function
> gem_execbuf, file ../lib/ioctl_wrappers.c:605:
> (pm_rpm:2032) ioctl_wrappers-CRITICAL: Failed assertion: __gem_execbuf(fd,
> execbuf) == 0
> (pm_rpm:2032) ioctl_wrappers-CRITICAL: error: -5 != 0
> Subtest gem-execbuf-stress failed.

These are definitely not the same problem. This is not the device being wedged before hand, but the guc exploding midtest.

(In reply to Martin Peres from comment #7)
> (In reply to Chris Wilson from comment #5)
> > Until the next time we have a wedged device.
> 
> Yeah... It's back... What should we do with this bug?
> 
> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_107/fi-cfl-guc/
> igt@kms_plane_scaling@pipe-c-scaler-with-pixel-format.html
> 
> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_107/fi-cfl-guc/
> igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt.html
> 
> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_107/fi-cfl-guc/
> igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt.html

The same as we do everytime, teach them to skip if they don't have the resources required to run their test. kms_frontbuffer_tracking is messy to try and get igt_require_gem() into the right subset.

(In reply to Chris Wilson from comment #9)
> (In reply to Martin Peres from comment #8)
> > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_109/fi-kbl-guc/
> > igt@pm_rpm@gem-execbuf-stress-extra-wait.html
> > 
> > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_109/fi-kbl-guc/
> > igt@pm_rpm@gem-execbuf-stress.html
> > 
> > (pm_rpm:2032) ioctl_wrappers-CRITICAL: Test assertion failure function
> > gem_execbuf, file ../lib/ioctl_wrappers.c:605:
> > (pm_rpm:2032) ioctl_wrappers-CRITICAL: Failed assertion: __gem_execbuf(fd,
> > execbuf) == 0
> > (pm_rpm:2032) ioctl_wrappers-CRITICAL: error: -5 != 0
> > Subtest gem-execbuf-stress failed.
> 
> These are definitely not the same problem. This is not the device being
> wedged before hand, but the guc exploding midtest.

Thanks, bug filed here: https://bugs.freedesktop.org/show_bug.cgi?id=107917

 This was very much reproducible every single run, now not seen since drmtip_116 (1 month, 1 week / 19 runs ago). Closing!