Bug 90003 - [BYT/IVB/HSW bisected] igt/gem_flink_race@flink_close and prime_self_import@reimport-vs-gem_close-race fails
Summary: [BYT/IVB/HSW bisected] igt/gem_flink_race@flink_close and prime_self_import@r...
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-13 05:56 UTC by ye.tian
Modified: 2017-10-06 14:30 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg info (113.98 KB, text/plain)
2015-04-13 05:56 UTC, ye.tian
no flags Details

Description ye.tian 2015-04-13 05:56:16 UTC
Created attachment 115042 [details]
dmesg info

System Environment:       
-----------------------------------------------------
Regression: Yes
Non-working platforms: BYT IVB HSW

==Kernel==
--------------------------------------------------
commit 631c2f8cb69ecbd7dd0494c37dd3c7fbd04de928
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Apr 11 00:21:05 2015 +0200

    drm-intel-nightly: 2015y-04m-10d-22h-20m-20s UTC integration manifest

==Bug detailed description==
Igt@gem_flink_race@flink_close and igt@prime_self_import@reimport-vs-gem_close-race fails on BYT IVB and HSW.
It’s kernel regression, By bisected, show the first bad commit is 618bf1b.
Chris said “it is just a test failure. The test never anticipated the kernel might allocate temporary objects for itself.”

commit 618bf1b7d5cc1fcb71dbb93a8f932d6441388a15
Author:     Chris Wilson <chris@chris-wilson.co.uk>
AuthorDate: Tue Apr 7 16:20:37 2015 +0100
Commit:     Daniel Vetter <daniel.vetter@ffwll.ch>
CommitDate: Wed Apr 8 13:32:28 2015 +0200

    drm/i915: Free batch pool when idle
    
    At runtime, this helps ensure that the batch pools are kept trim and
    fast. Then at suspend, this releases memory that we do not need to
    restore. It also ties into the oom-notifier to ensure that we recover as
    much kernel memory as possible during OOM.

Output:
----------------------------
root@x-hsw24:/GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests# ./gem_flink_race --run-subtest flink_close
IGT-Version: 1.10-g007ff02 (x86_64) (Linux: 4.0.0-rc7_drm-intel-nightly_631c2f_20150411+ x86_64)
leaked -4 objects
Test assertion failure function test_flink_close, file gem_flink_race.c:199:
Failed assertion: obj_count == 0
error: -4 != 0
Stack trace:
  #0 [__igt_fail_assert+0xfc]
  #1 [__real_main202+0x321]
  #2 [main+0x21]
  #3 [__libc_start_main+0xf5]
  #4 [_start+0x29]
  #5 [<unknown>+0x29]
Subtest flink_close failed.
**** DEBUG ****
Test requirement passed: fd >= 0
Test requirement passed: fd >= 0
leaked -4 objects
Test assertion failure function test_flink_close, file gem_flink_race.c:199:
Failed assertion: obj_count == 0
error: -4 != 0
****  END  ****
Subtest flink_close: FAIL (5.043s)

1, ./gem_flink_race --run-subtest flink_close
Comment 1 Chris Wilson 2015-04-13 09:17:17 UTC
commit 2e526ae9cd05f4f2c2e166071b78c68564e191aa
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Apr 12 13:32:17 2015 +0100

    igt/gem_flink_race: Explicitly quiesce the GPU before counting objects
    
    By explicitly quiescing the GPU we force it to a known and ideally
    identical state when counting objects. In particular, this should make
    the batch-pool status the same and not cause us to detect a negative
    leak.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Comment 2 ye.tian 2015-04-13 09:39:44 UTC
Test on the latest kernel and latest igt, ./gem_flink_race --run-subtest flink_close is good, but prime_self_import case still fails.

output:
---------------
root@x-hsw24:/GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests# ./gem_flink_race --run-subtest flink_close
IGT-Version: 1.10-g2e526ae (x86_64) (Linux: 4.0.0-rc7_drm-intel-nightly_631c2f_20150411+ x86_64)
leaked 0 objects
Subtest flink_close: SUCCESS (5.001s)


root@x-hsw24:/GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests# ./prime_self_import --run-subtest reimport-vs-gem_close-race
IGT-Version: 1.10-g2e526ae (x86_64) (Linux: 4.0.0-rc7_drm-intel-nightly_631c2f_20150411+ x86_64)
leaked -4 objects
Test assertion failure function test_reimport_close_race, file prime_self_import.c:302:
Failed assertion: obj_count == 0
error: -4 != 0
Stack trace:
  #0 [__igt_fail_assert+0xfc]
  #1 [test_reimport_close_race+0x1aa]
  #2 [__real_main442+0xcd]
  #3 [main+0x21]
  #4 [__libc_start_main+0xf5]
  #5 [_start+0x29]
  #6 [<unknown>+0x29]
Subtest reimport-vs-gem_close-race failed.
**** DEBUG ****
Test requirement passed: fd >= 0
Test requirement passed: fd >= 0
leaked -4 objects
Test assertion failure function test_reimport_close_race, file prime_self_import.c:302:
Failed assertion: obj_count == 0
error: -4 != 0
****  END  ****
Subtest reimport-vs-gem_close-race: FAIL (5.001s)
You have new mail in /var/spool/mail/root
Comment 3 Chris Wilson 2015-04-13 09:50:22 UTC
commit 9fd6e07369837ee268097e7aae4c8dea05431fa1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Apr 13 10:48:08 2015 +0100

    igt/prime_self_import: Ensure driver state is consistent between counts
    
    Similar to gem_flink_race, we need to make sure that when we count
    objects, the driver is in an identical state. We do this by flushing all
    work before counting.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90003
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Comment 4 ye.tian 2015-04-13 09:55:13 UTC
Verified it on the latest igt.

output
-------
root@x-hsw24:/GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests# ./prime_self_import --run-subtest reimport-vs-gem_close-race
IGT-Version: 1.10-g9fd6e07 (x86_64) (Linux: 4.0.0-rc7_drm-intel-nightly_631c2f_20150411+ x86_64)
leaked 0 objects
Subtest reimport-vs-gem_close-race: SUCCESS (5.000s)
Comment 5 Elizabeth 2017-10-06 14:30:37 UTC
Closing old verified.


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.