Bug 89669 - [SNB+]igt/drv_getparams fails
Summary: [SNB+]igt/drv_getparams fails
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-03-19 03:19 UTC by lu hua
Modified: 2017-10-06 14:30 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg (121.75 KB, text/plain)
2015-03-19 03:19 UTC, lu hua
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description lu hua 2015-03-19 03:19:34 UTC
Created attachment 114457 [details]
dmesg

==System Environment==
--------------------------
Regression: not sure, new case

==kernel==
--------------------------
drm-intel-fixes/319c1d420a0b62d9dbb88104afebaabc968cdbfa
commit 319c1d420a0b62d9dbb88104afebaabc968cdbfa
Author: Xi Ruoyao <xry111@outlook.com>
Date:   Thu Mar 12 20:16:32 2015 +0800

    drm/i915: Ensure plane->state->fb stays in sync with plane->fb

    plane->state->fb and plane->fb should always reference the same FB so
    that atomic and legacy codepaths have the same view of display state.
    However, there are some places in kernel code that directly set
    plane->fb and neglect to update plane->state->fb. If we never do a
    successful update through the atomic pipeline, the RmFB cleanup code
    will look at the plane->state->fb pointer, which has never actually
    been set to a legitimate value, and try to clean it up, leading to
    BUG's.

    Add a quick helper function to synchronize plane->state->fb with
    plane->fb and call it everywhere the driver tries to manually set
    plane->fb outside of the atomic pipeline. In this function, use
    drm_atomic_set_fb_for_plane instead of writing plane->state->fb
    directly to keep the reference count right.

==Bug detailed description==
-----------------------------
It fails on drm-intel-fixes kernel, works well on drm-intel-nightly kernel.

output:
IGT-Version: 1.10-ga172676 (x86_64) (Linux: 4.0.0-rc4_drm-intel-fixes_319c1d_20150317+ x86_64)
Test assertion failure function eu_total, file drv_getparams.c:127:
Failed assertion: ret == -19
Last errno: 22, Invalid argument
error: -22 != -19
Subtest eu-total failed.
**** DEBUG ****
Test assertion failure function eu_total, file drv_getparams.c:127:
Failed assertion: ret == -19
Last errno: 22, Invalid argument
error: -22 != -19
****  END  ****
Subtest eu-total: FAIL (0.000s)

==Reproduce steps==
---------------------------- 
1. ./drv_getparams --run-subtest eu-total
Comment 1 Jesse Barnes 2015-03-23 20:05:26 UTC
This is actually expected behavior.  Older kernels don't support this param, so will return -EINVAL.  Newer kernels will return the new, expected error code of ENODEV on older devices, and a valid value for newer ones.

Not sure how we want to handle this... it shouldn't be a problem going forward, so we could just wontfix it.
Comment 2 Daniel Vetter 2015-03-25 13:39:58 UTC
Author: Jeff McGee <jeff.mcgee@intel.com>
Date:   Tue Mar 24 11:30:57 2015 -0700

    tests/drv_getparams: Skip instead of fail on EINVAL


Nope this isn't WONTFIX, igt generally should detect older kernels (within limits) and skip correctly.
Comment 3 lu hua 2015-03-26 03:13:50 UTC
Fixed. It skips on the latest igt and -fixes kernel.
IGT-Version: 1.10-g1cfcca6 (x86_64) (Linux: 4.0.0-rc5_drm-intel-fixes_771246_20150326+ x86_64)
Test requirement not met in function subslice_total, file drv_getparams.c:80:
Test requirement: !(ret == -EINVAL)
Interface not supported by kernel
Last errno: 22, Invalid argument
Subtest subslice-total: SKIP (0.000s)
Test requirement not met in function eu_total, file drv_getparams.c:117:
Test requirement: !(ret == -EINVAL)
Interface not supported by kernel
Last errno: 22, Invalid argument
Subtest eu-total: SKIP (0.000s)
Comment 4 Elizabeth 2017-10-06 14:30:53 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.