[Bug 107341] [CI][BAT] igt@amdgpu/amd_prime@amd-to-i915 - fail - Failed assertion: __vgem_fence_signal(fd, fence) == 0 due to setup time taking longer than 10s
https://bugs.freedesktop.org/show_bug.cgi?id=107341
Bug ID: 107341 Summary: [CI][BAT] igt@amdgpu/amd_prime@amd-to-i915 - fail - Failed assertion: __vgem_fence_signal(fd, fence) == 0 due to setup time taking longer than 10s Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: IGT Assignee: dri-devel@lists.freedesktop.org Reporter: martin.peres@free.fr
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4519/fi-kbl-8809g/igt@amdgpu...
(amd_prime:4831) igt_vgem-CRITICAL: Test assertion failure function vgem_fence_signal, file ../lib/igt_vgem.c:193: (amd_prime:4831) igt_vgem-CRITICAL: Failed assertion: __vgem_fence_signal(fd, fence) == 0 (amd_prime:4831) igt_vgem-CRITICAL: error: -110 != 0 Subtest amd-to-i915 failed.
Chris already commented that "We need to tune the setup to run within 10s or use a sw_sync fence instead of a vgem plug."
https://bugs.freedesktop.org/show_bug.cgi?id=107341
Martin Peres martin.peres@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Whiteboard| |ReadyForDev
https://bugs.freedesktop.org/show_bug.cgi?id=107341
--- Comment #1 from Chris Wilson chris@chris-wilson.co.uk --- It looks to be due to amdgpu_gem_map_attach() which is synchronous and stalls for the inflight fence before allowing i915 to use it.
https://bugs.freedesktop.org/show_bug.cgi?id=107341
Chris Wilson chris@chris-wilson.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #2 from Chris Wilson chris@chris-wilson.co.uk --- commit 6e11ea9de9576a644045ffdc2067c09bc2012eda Author: Chris Wilson chris@chris-wilson.co.uk Date: Wed Jan 30 10:55:17 2019 +0000
drm/amdgpu: Transfer fences to dmabuf importer
amdgpu only uses shared-fences internally, but dmabuf importers rely on implicit write hazard tracking via the reservation_object.fence_excl. For example, the importer use the write hazard for timing a page flip to only occur after the exporter has finished flushing its write into the surface. As such, on exporting a dmabuf, we must either flush all outstanding fences (for we do not know which are writes and should have been exclusive) or alternatively create a new exclusive fence that is the composite of all the existing shared fences, and so will only be signaled when all earlier fences are signaled (ensuring that we can not be signaled before the completion of any earlier write).
v2: reservation_object is already locked by amdgpu_bo_reserve() v3: Replace looping with get_fences_rcu and special case the promotion of a single shared fence directly to an exclusive fence, bypassing the fence array. v4: Drop the fence array ref after assigning to reservation_object
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107341 Testcase: igt/amd_prime/amd-to-i915 References: 8e94a46c1770 ("drm/amdgpu: Attach exclusive fence to prime exported bo's. (v5)") Signed-off-by: Chris Wilson chris@chris-wilson.co.uk Cc: Alex Deucher alexander.deucher@amd.com Cc: "Christian König" christian.koenig@amd.com Reviewed-by: "Christian König" christian.koenig@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com
https://bugs.freedesktop.org/show_bug.cgi?id=107341
Martin Peres martin.peres@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #3 from Martin Peres martin.peres@free.fr --- (In reply to Chris Wilson from comment #2)
commit 6e11ea9de9576a644045ffdc2067c09bc2012eda Author: Chris Wilson chris@chris-wilson.co.uk Date: Wed Jan 30 10:55:17 2019 +0000
drm/amdgpu: Transfer fences to dmabuf importer amdgpu only uses shared-fences internally, but dmabuf importers rely on implicit write hazard tracking via the reservation_object.fence_excl. For example, the importer use the write hazard for timing a page flip to only occur after the exporter has finished flushing its write into the surface. As such, on exporting a dmabuf, we must either flush all outstanding fences (for we do not know which are writes and should have been exclusive) or alternatively create a new exclusive fence that is the composite of all the existing shared fences, and so will only be signaled when all earlier fences are signaled (ensuring that we can not be signaled before the completion of any earlier write). v2: reservation_object is already locked by amdgpu_bo_reserve() v3: Replace looping with get_fences_rcu and special case the promotion of a single shared fence directly to an exclusive fence, bypassing the fence array. v4: Drop the fence array ref after assigning to reservation_object Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107341 Testcase: igt/amd_prime/amd-to-i915 References: 8e94a46c1770 ("drm/amdgpu: Attach exclusive fence to primeexported bo's. (v5)") Signed-off-by: Chris Wilson chris@chris-wilson.co.uk Cc: Alex Deucher alexander.deucher@amd.com Cc: "Christian König" christian.koenig@amd.com Reviewed-by: "Christian König" christian.koenig@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com
This is indeed fixed! Thanks!
https://bugs.freedesktop.org/show_bug.cgi?id=107341
--- Comment #4 from CI Bug Log cibuglog@gmail.com --- The CI Bug Log issue associated to this bug has been archived.
New failures matching the above filters will not be associated to this bug anymore.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org