Increasing the priority as it is likely a regression caused by Linux 4.17-rc1.

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.

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_24/fi-byt-j1900/igt@kms_flip@2x-absolute-wf_vblank-interruptible.html

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.

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.

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.