Summary: | [CI][SHARDS] igt@kms_flip@flip-vs-fences-interruptible - dmesg-warn- BUG: unable to handle kernel paging request | ||
---|---|---|---|
Product: | DRI | Reporter: | Lakshmi <lakshminarayana.vudum> |
Component: | DRM/Intel | Assignee: | Andi <andi.shyti> |
Status: | RESOLVED WORKSFORME | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
Severity: | normal | ||
Priority: | high | CC: | intel-gfx-bugs, oleksandr |
Version: | DRI git | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | Triaged, ReadyForDev | ||
i915 platform: | ICL | i915 features: | GEM/Other |
Description
Lakshmi
2019-03-28 15:04:07 UTC
The CI Bug Log issue associated to this bug has been updated. ### New filters associated * ICL: igt@kms_flip@flip-vs-fences-interruptible - dmesg-warn- BUG: unable to handle kernel paging request - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5824/shard-iclb2/igt@kms_flip@flip-vs-fences-interruptible.html The CI Bug Log issue associated to this bug has been updated. ### New filters associated * ICL: igt@runner@aborted - fail - Previous test: kms_flip (flip-vs-fences-interruptible) - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5824/shard-iclb2/igt@runner@aborted.html A CI Bug Log filter associated to this bug has been updated: {- ICL: igt@kms_flip@flip-vs-fences-interruptible - dmesg-warn- BUG: unable to handle kernel paging request -} {+ ICL: igt@kms_flip@flip-vs-fences-interruptible - dmesg-warn- (BUG: unable to handle kernel paging request|general protection fault: 0000) +} New failures caught by the filter: * https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5831/shard-iclb6/igt@kms_flip@flip-vs-fences-interruptible.html A CI Bug Log filter associated to this bug has been updated: {- ICL: igt@kms_flip@flip-vs-fences-interruptible - dmesg-warn- (BUG: unable to handle kernel paging request|general protection fault: 0000) -} {+ ICL: igt@kms_flip@flip-vs-fences-interruptible / igt@gem_create@create-clear - dmesg-warn- (BUG: unable to handle kernel paging request|general protection fault: 0000) +} No new failures caught with the new filter A CI Bug Log filter associated to this bug has been updated: {- ICL: igt@runner@aborted - fail - Previous test: kms_flip (flip-vs-fences-interruptible) -} {+ ICL: igt@runner@aborted - fail - Previous test: (kms_flip|gem_create) +} No new failures caught with the new filter (In reply to CI Bug Log from comment #4) > A CI Bug Log filter associated to this bug has been updated: > > {- ICL: igt@kms_flip@flip-vs-fences-interruptible - dmesg-warn- (BUG: unable > to handle kernel paging request|general protection fault: 0000) -} > {+ ICL: igt@kms_flip@flip-vs-fences-interruptible / > igt@gem_create@create-clear - dmesg-warn- (BUG: unable to handle kernel > paging request|general protection fault: 0000) +} > > No new failures caught with the new filter https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5816/shard-iclb8/igt@gem_create@create-clear.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5808/shard-iclb6/igt@gem_create@create-clear.html Since the test igt@kms_flip@flip-vs-fences-interruptible is using execbuf and GTT fences, and we also fail at igt@gem_create@create-clear, there is a chance that this is not a Linux issue, but instead a GEM one. Given that this issue happened 4 times in a week on 4 different machines and that the outcome of this issue is a oops, which breaks the users' machines until they reboot, it is fair to increase the priority to highest. Next step would be to see if this is reproducible consistently and bisect to the culprit commit (wherever that may be). gem_create@create-clear might be the easier way to trigger this. We also see page corruption in gem_create/create-clear on shard-snb. Tomi did some digging and found that it first occurred circa CI_DRM_5800 (which is about a hundred runs after gem_create/create-clear was introduced, so reasonable to conclude that the sporadic failures were introduced by a later kernel update). The implication is that this an -rc1 failure. *** Bug 110340 has been marked as a duplicate of this bug. *** Andi, can you see if you can pinpoint the kernel commit that introduced this? BIOS was updated on shards 10th of Apr. Lowering the priority because the issue got seen twice in 13 runs, but then nothing for 105 runs. We'll close it next week, when the issue pops up at the top of the open bugs view of cibuglog. Andi, would be great if you could try to reproduce on CI_DRM_5824 and, if you succeed try to reproduce on drmtip? This would give us confidence that this indeed was a SW issue :) (In reply to Martin Peres from comment #12) > Lowering the priority because the issue got seen twice in 13 runs, but then > nothing for 105 runs. We'll close it next week, when the issue pops up at > the top of the open bugs view of cibuglog. It popped up again at the top, now is time to close it since it did not happen again! Last failure happened on CI_DRM_5831, now not seen for 164 runs which is above the 10x rule. Closing! If it happens again, go and check whether [1] fixes it. [1] https://lore.kernel.org/lkml/1558711908-15688-1-git-send-email-suzuki.poulose@arm.com/ |
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.