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
Summary: [CI][BAT] igt@amdgpu/amd_prime@amd-to-i915 - fail - Failed assertion: __vgem_...
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: IGT (show other bugs)
Version: XOrg git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2018-07-23 14:22 UTC by Martin Peres
Modified: 2019-02-14 15:36 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Peres 2018-07-23 14:22:44 UTC
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4519/fi-kbl-8809g/igt@amdgpu_amd_prime@amd-to-i915.html

(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."
Comment 1 Chris Wilson 2018-08-06 12:39:03 UTC
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.
Comment 2 Chris Wilson 2019-02-04 08:57:40 UTC
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>
Comment 3 Martin Peres 2019-02-14 15:36:25 UTC
(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 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>

This is indeed fixed! Thanks!
Comment 4 CI Bug Log 2019-02-14 15:36:49 UTC
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.


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.