Bug 101859 - [IGT] [BYT] Fail test igt@gem_lut_handle
Summary: [IGT] [BYT] Fail test igt@gem_lut_handle
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2017-07-20 20:21 UTC by Ricardo Madrigal
Modified: 2018-02-13 16:40 UTC (History)
1 user (show)

See Also:
i915 platform: BYT
i915 features: GEM/execlists


Attachments
result.log (644 bytes, text/plain)
2017-07-20 20:21 UTC, Ricardo Madrigal
no flags Details
dmesg.log (47.37 KB, text/plain)
2017-07-20 20:21 UTC, Ricardo Madrigal
no flags Details
kern.log (82.38 KB, text/plain)
2017-07-20 20:22 UTC, Ricardo Madrigal
no flags Details

Description Ricardo Madrigal 2017-07-20 20:21:43 UTC
Created attachment 132802 [details]
result.log

The following tests fail on BYT with latest configuration

====================================================
Test list
====================================================
igt@gem_lut_handle

====================================================
Graphic Stack
====================================================
Component: drm
     tag: libdrm-2.4.81-31-g23e234a
     commit: 23e234a3503f51b9d9c585123d33b936f522808d
Component: cairo
    tag: 1.15.6-2-g57b4050
    commit: 57b40507dda3f58dfc8635548d606b86dc7bcf51
Component: intel-gpu-tools
    tag: intel-gpu-tools-1.19-96-gfb1ddc4
    commit: fb1ddc47003ad6a683db79beeb81b6cbab1feb7c
Component: piglit
    tag: piglit-v1
    commit: 56e7e5583cd4a3ca15a8cda154d46d168959dd25

======================================
             Hardware
======================================
motherboard model          : .................................
motherboard id             : DN2820FYK
form factor                : Desktop
manufacturer               : .................................
cpu family                 : Celeron
cpu family id              : 6
cpu information            : Intel(R) Celeron(R) CPU  N2830  @ 2.16GHz
gpu card                   : Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display (rev 0e) (prog-if 00 [VGA controller])
memory ram                 : 7.66 GB
max memory ram             : 8 GB
cpu thread                 : 2
cpu core                   : 2
cpu model                  : 55
cpu stepping               : 8
socket                     : <OUT OF SPEC>
signature                  : Type 0, Family 6, Model 55, Stepping 8
hard drive                 : 111GiB (120GB)
current cd clock frequency : 266667 kHz
maximum cd clock frequency : 400000 kHz
displays connected         : HDMI-A-1
Comment 1 Ricardo Madrigal 2017-07-20 20:21:59 UTC
Created attachment 132803 [details]
dmesg.log
Comment 2 Ricardo Madrigal 2017-07-20 20:22:13 UTC
Created attachment 132804 [details]
kern.log
Comment 3 Elizabeth 2017-07-21 15:47:10 UTC
Adding tag into "Whiteboard" field - ReadyForDev
*Status is correct
*Platform is included
*Feature is included
*Priority and Severity correctly set
*Logs included
Comment 4 Chris Wilson 2017-08-29 09:56:01 UTC
commit a575c6761757232ea2c7dc9f370640754b90cc69
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Aug 28 11:46:31 2017 +0100

    drm/i915: Recreate vmapping even when the object is pinned
    
    Sometimes we know we are the only user of the bo, but since we take a
    protective pin_pages early on, an attempt to change the vmap on the
    object is denied because it is busy. i915_gem_object_pin_map() cannot
    tell from our single pin_count if the operation is safe. Instead we must
    pass that information down from the caller in the manner of
    I915_MAP_OVERRIDE.
    
    This issue has existed from the introduction of the mapping, but was
    never noticed as the only place where this conflict might happen is for
    cached kernel buffers (such as allocated by i915_gem_batch_pool_get()).
    Until recently there was only a single user (the cmdparser) so no
    conflicts ever occurred. However, we now use it to allocate batches for
    different operations (using MAP_WC on !llc for writes) in addition to the
    existing shadow batch (using MAP_WB for reads).
    
    We could either keep both mappings cached, or use a different write
    mechanism if we detect a MAP_WB already exists (i.e. clflush
    afterwards), but as we haven't seen this issue in the wild (it requires
    hitting the GPU reloc path in addition to the cmdparser) for simplicity
    just allow the mappings to be recreated.
    
    v2: Include the i915_MAP_OVERRIDE bit in the enum so the compiler knows
    about all the valid values.
    
    Fixes: 7dd4f6729f92 ("drm/i915: Async GPU relocation processing")
    Testcase: igt/gem_lut_handle # byt, completely by accident
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20170828104631.8606-1-chris@chris-wilson.co.uk
    Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Comment 5 Elizabeth 2017-10-04 19:16:08 UTC
Verified. Closing.

$ : sudo -E ./intel-graphics/intel-gpu-tools/tests/gem_lut_handle
IGT-Version: 1.19-g1e99f8b (x86_64) (Linux: 4.14.0-rc3-drm-tip-ww40-commit-2f14e31+ x86_64)
SUCCESS (92.642s)
Comment 6 Elizabeth 2018-02-13 16:40:50 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.