Summary: | [CI] igt@*(suspend|hibernate)* | igt@kms_cursor_crc@* - vblank wait timed out on crtc 0 | ||
---|---|---|---|
Product: | DRI | Reporter: | Martin Peres <martin.peres> |
Component: | DRM/Intel | Assignee: | Stanislav Lisovskiy <stanislav.lisovskiy> |
Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
Severity: | normal | ||
Priority: | medium | CC: | intel-gfx-bugs |
Version: | XOrg git | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | ReadyForDev | ||
i915 platform: | ALL | i915 features: | display/Other |
Bug Depends on: | |||
Bug Blocks: | 106319 |
Description
Martin Peres
2018-04-16 18:14:32 UTC
Increasing the priority as it is likely a regression from Linux 4.17-rc1. Also seen on suspend tests: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8764/shard-hsw2/igt@gem_exec_suspend@basic-s3-devices.html Also seen on non-shard HSW: https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_24/fi-hsw-4770/igt@gem_eio@suspend.html Also seen on SNB: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4446/shard-snb5/igt@gem_exec_suspend@basic-s3-devices.html Also seen on ILK: https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_25/fi-ilk-650/igt@gem_exec_suspend@basic-s3-devices.html I was able to reproduce this on HSW. Trying to bisect. Petri, any further findings? Bisect landed on commit 9eb31227cbccd3a37da0f42604f1ab5fc556bc53 with some certainty. The issue does not reproduce on its parents with 200-something runs. The results are suspect though because that commit is a merge commit, and it merges changes in crypto. I did a piecemeal merge and bisected that, and the latter bisect landed on a commit merging changes for crypto/ux500/hash/. Again, with quite a bit of certainty. I applied a revert of the merged commit into the merge commit the original bisect landed on and ran some 20 rounds on the result. The issue does not reproduce. Before you can celebrate finding the culprit, I'd like to point out that the commit in question changes code that isn't even built with my .config. More test rounds to follow. Reverting the revert changes nothing as expected, bisecting is suspect. I'm tabling this bisecting effort for now. Lowering prio. Looks drm_wait_one_vblank fails because it is being called from intel_display_suspend/resume, when vblank interrupts are not going to happen because system is in the suspended state. This causes a time out if were unlucky not to have any vblank events accumulated in the queue. I guess the fix should be that we check if we are not in suspended state in intel_pre_plane_update, otherwise it makes no sense to wait for it. I have done a small fix, so I just need to verify it now. Is this already fixed? (In reply to Jani Saarinen from comment #12) > Is this already fixed? I can't tell yet using the CI results, because the chances of it happening were slim. Maybe Stan has landed a fix? Stan, can you comment here? I have investigated this issue and figured out that drm_wait_one_vblank was always timing out when going to suspend or resume. My idea was that this happens because it sometimes waits for vblank when vblank interrupts aren't turned on yet. However after some source code investigation it turned out that it at least tries to turn on the interrupts before intel_display_suspend/resume is called. This seems to be not reproducible even in CI at the moment, so my guess was that something has been fixed already or the chances of reproducing it got even more slim. Based on the investigation, I assume this issue has been fixed. Last seen this issue 1 month 1 week ago (or) 24 rounds of drmtip execution. This issue used to appear regularly. Closing this bug as resolved/fixed. |
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.