| Summary: | [CI][SHARDS] igt@* - fail - gem exec bo fails with error -5 on gen9 | ||
|---|---|---|---|
| Product: | DRI | Reporter: | Martin Peres <martin.peres> |
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Status: | CLOSED WORKSFORME | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | intel-gfx-bugs |
| Version: | XOrg git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | ReadyForDev | ||
| i915 platform: | BXT, CFL, GLK, KBL, SKL | i915 features: | GEM/Other |
|
Description
Martin Peres
2018-07-17 11:11:04 UTC
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! |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.