Bug 105561 - [CI] igt@gem_ctx_switch@basic-all-heavy - timeout - Test run time exceeded timeout value (300 seconds)
Summary: [CI] igt@gem_ctx_switch@basic-all-heavy - timeout - Test run time exceeded ti...
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: Other All
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-16 17:57 UTC by Martin Peres
Modified: 2018-04-20 10:58 UTC (History)
1 user (show)

See Also:
i915 platform: GLK, SNB
i915 features: GEM/Other


Attachments

Description Martin Peres 2018-03-16 17:57:52 UTC
An internal exception that should have been handled was not:
Test run time exceeded timeout value (300 seconds)

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3939/shard-glkb1/igt@gem_ctx_switch@basic-all-heavy.html

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3939/shard-snb2/igt@gem_ctx_switch@basic-all-heavy.html
Comment 1 Martin Peres 2018-03-16 17:58:56 UTC
This likely comes after Tomi changed the timeout from 600 to 300 seconds in piglit's igt.py.
Comment 2 Martin Peres 2018-03-16 17:59:59 UTC

*** This bug has been marked as a duplicate of bug 105556 ***
Comment 3 Marta Löfstedt 2018-03-19 07:03:58 UTC
This is for sure not a duplicate of bug 105556, since that bug is softdog incomplete and this is piglit timeout due to change in the CI system configuration. Before the configuration change the softdog did not hit the pinpointed machines on the test.
Comment 4 Marta Löfstedt 2018-03-20 09:46:29 UTC
I will archive this from cibuglog since the issue doesn't appear to happend again. I will not close since it was created by Martin.
Comment 5 Chris Wilson 2018-03-23 10:36:05 UTC
commit 20b8799898c844ad57e9cdb0238ffb7a44140d89 (HEAD, upstream/master)
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Mar 16 15:53:57 2018 +0000

    igt/gem_ctx_switch: Measure qlen for timing loops
    
    Some platforms may execute the heavy workload very slowly, such that
    using a batch of 1024 takes tens of seconds and immediately overrunning
    the 5s timeout on a pass. Added up over a few dozen passes, this turns a
    120 second test into 10 minutes. Counter this by doing a warmup loop to
    estimate the appropriate queue len for timing.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Comment 6 Jani Saarinen 2018-04-20 10:58:10 UTC
Closing this now.


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.