Bug 106087

Summary: [CI] igt@kms_flip@(2x-)absolute-wf_vblank-interruptible - Failed assertion: timercmp(&es->last_received_ts, &es->current_ts, <)
Product: DRI Reporter: Martin Peres <martin.peres>
Component: DRM/IntelAssignee: Stanislav Lisovskiy <stanislav.lisovskiy>
Status: CLOSED WORKSFORME QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: high CC: intel-gfx-bugs
Version: XOrg git   
Hardware: Other   
OS: All   
Whiteboard: ReadyForDev
i915 platform: BYT, GLK i915 features: display/Other
Bug Depends on:    
Bug Blocks: 106319    

Description Martin Peres 2018-04-16 18:16:47 UTC
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4055/shard-glk3/igt@kms_flip@absolute-wf_vblank-interruptible.html

	
(kms_flip:1133) CRITICAL: Test assertion failure function check_state, file ../tests/kms_flip.c:488:
(kms_flip:1133) CRITICAL: Failed assertion: timercmp(&es->last_received_ts, &es->current_ts, <)
(kms_flip:1133) CRITICAL: Last errno: 25, Inappropriate ioctl for device
(kms_flip:1133) CRITICAL: vblank ts before the vblank was issued!
timerdiff -1.989315
Subtest absolute-wf_vblank-interruptible failed.
Comment 1 Martin Peres 2018-04-16 18:17:20 UTC
Increasing the priority as it is likely a regression caused by Linux 4.17-rc1.
Comment 2 Martin Peres 2018-04-20 12:30:57 UTC
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_23/fi-byt-n2820/igt@kms_flip@absolute-wf_vblank-interruptible.html

(kms_flip:1579) CRITICAL: Test assertion failure function check_state, file ../tests/kms_flip.c:488:
(kms_flip:1579) CRITICAL: Failed assertion: timercmp(&es->last_received_ts, &es->current_ts, <)
(kms_flip:1579) CRITICAL: Last errno: 25, Inappropriate ioctl for device
(kms_flip:1579) CRITICAL: vblank ts before the vblank was issued!
timerdiff -1.985964
Subtest absolute-wf_vblank-interruptible failed.
Comment 4 Martin Peres 2018-05-30 22:43:37 UTC
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_53/fi-glk-j4005/igt@kms_flip@blocking-absolute-wf_vblank.html

(kms_flip:1724) CRITICAL: Test assertion failure function check_state, file ../tests/kms_flip.c:488:
(kms_flip:1724) CRITICAL: Failed assertion: timercmp(&es->last_received_ts, &es->current_ts, <)
(kms_flip:1724) CRITICAL: Last errno: 25, Inappropriate ioctl for device
(kms_flip:1724) CRITICAL: vblank ts before the vblank was issued!
timerdiff -1.997393
Subtest blocking-absolute-wf_vblank failed.
Comment 5 Martin Peres 2018-06-08 09:44:07 UTC
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_57/fi-glk-j4005/igt@kms_flip@wf_vblank-ts-check.html

(kms_flip:2519) CRITICAL: Test assertion failure function check_state, file ../tests/kms_flip.c:488:
(kms_flip:2519) CRITICAL: Failed assertion: timercmp(&es->last_received_ts, &es->current_ts, <)
(kms_flip:2519) CRITICAL: Last errno: 25, Inappropriate ioctl for device
(kms_flip:2519) CRITICAL: vblank ts before the vblank was issued!
timerdiff -1.999830
Subtest wf_vblank-ts-check failed.
Comment 6 Stanislav Lisovskiy 2018-06-18 11:18:14 UTC
According to the log and my investigations it looks like, for some reason vblank timestamp doesn't get updated in time, for the last 2 calls timestamp has exactly same number, while received timestamp value is correct. 
According to the information from Martin this looks like a regression since 4.16, I've noticed there were some vblank optimizations, which came with 4.17-rc1, for example like this one:

commit 68036b08b91bc491ccc308f902616a570a49227c
Author: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Date:   Fri Feb 2 21:13:00 2018 -0800

    drm/vblank: Do not update vblank count if interrupts are already disabled.
    
    Updating vblank counts requires register reads and these reads may not
    return meaningful values if the device was in a low power state after
    vblank interrupts were last disabled. So, update the count only if vblank
    interrupts are enabled. Secondly, this means the registers should be read
    before disabling vblank interrupts.
    
    v2: Don't check vblank->enabled outside it's lock (Chris)

However currently this is only suspicion and I might be wrong, I have reverted this commit and now testing with my local machine, however as this issue doesn't always reproduce this might take a while.

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.