Bug 106344 - [CI] igt@sw_sync@sync_multi_consumer_producer - fail - Failed assertion: counter == MULTI_CONSUMER_PRODUCER_THREADS * MULTI_CONSUMER_PRODUCER_ITERATIONS
Summary: [CI] igt@sw_sync@sync_multi_consumer_producer - fail - Failed assertion: coun...
Status: CLOSED WORKSFORME
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: Other All
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-02 09:15 UTC by Martin Peres
Modified: 2018-06-19 14:26 UTC (History)
1 user (show)

See Also:
i915 platform: PNV
i915 features: GEM/Other


Attachments

Description Martin Peres 2018-05-02 09:15:01 UTC
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_29/fi-pnv-d510/igt@sw_sync@sync_multi_consumer_producer.html

(sw_sync:1950) CRITICAL: Test assertion failure function test_sync_multi_consumer_producer, file ../tests/sw_sync.c:643:
(sw_sync:1950) CRITICAL: Failed assertion: counter == MULTI_CONSUMER_PRODUCER_THREADS * MULTI_CONSUMER_PRODUCER_ITERATIONS
(sw_sync:1950) CRITICAL: Last errno: 2, No such file or directory
(sw_sync:1950) CRITICAL: Counter has unexpected value.
Subtest sync_multi_consumer_producer failed.
Comment 1 Chris Wilson 2018-05-02 10:44:16 UTC
I suspect it's just a thread-safety issue around the test's counter.
Comment 2 Martin Peres 2018-06-15 09:04:16 UTC
Not seen since drmtip_29 (1 month, 2 weeks / 33 runs ago), closing!
Comment 3 Chris Wilson 2018-06-15 11:07:47 UTC
Applied

commit 91f5d4665b07f073c78abd3cd4b8e0e347dbf638 (upstream/master)
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed May 2 10:24:26 2018 +0100

    igt/sw_sync: Wrap threaded counter manipulation with mb
    
    sw_sync/sync_multi_consumer_producer was communicating between threads
    using the sw_sync ioctl and manipulating a shared volatile counter.
    However, the ioctl itself does not imply a memory barrier, and so
    different CPUs may see different states of the counter (the volatile
    making GCC perform the operation in stages making the race even more
    likely). Instead of using volatile, use locked operations to make the
    counter manipulation thread-safe.
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=106344
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

for good measure.
Comment 4 Jani Saarinen 2018-06-19 14:26:02 UTC
Closing, thanks.


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.