| Summary: | [ILK]I-G-T/kms_flip subtest: 'wf_vblank-vs-modeset' fail | ||||||
|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | yanbing <bingx.a.yan> | ||||
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||
| Severity: | normal | ||||||
| Priority: | medium | CC: | bingx.a.yan | ||||
| Version: | XOrg git | ||||||
| Hardware: | Other | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Attachments: |
|
||||||
|
Description
yanbing
2013-01-25 05:52:51 UTC
Yeah, there's a funky race somewhere still. I sometimes see test fail at first run, too :( One way I can reproduce this on current nightly 100% on IVB if the console is blanked when I start the test: # echo 1 > /sys/class/graphics/fb0/blank # kms_flip --run-subtest wf_vblank-vs-modeset Could you yanbing try this too? (In reply to comment #2) > One way I can reproduce this on current nightly 100% on IVB if the console > is blanked when I start the test: > > # echo 1 > /sys/class/graphics/fb0/blank > # kms_flip --run-subtest wf_vblank-vs-modeset > > Could you yanbing try this too? Could you also try the patch attached to bug #60002? (In reply to comment #3) > (In reply to comment #2) > > One way I can reproduce this on current nightly 100% on IVB if the console > > is blanked when I start the test: > > > > # echo 1 > /sys/class/graphics/fb0/blank > > # kms_flip --run-subtest wf_vblank-vs-modeset > > > > Could you yanbing try this too? > > Could you also try the patch attached to bug #60002? I apply this patch on -nightly top, then loop running this case 20 times, all passed, I double checked ILK and IVB platform, Both worked well. But I don't know whether it's enough to judge this bug is fixed, because I see yanbing describe that this issue is not stable reproduced. (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > One way I can reproduce this on current nightly 100% on IVB if the console > > > is blanked when I start the test: > > > > > > # echo 1 > /sys/class/graphics/fb0/blank > > > # kms_flip --run-subtest wf_vblank-vs-modeset > > > > > > Could you yanbing try this too? > > > > Could you also try the patch attached to bug #60002? > > I apply this patch on -nightly top, then loop running this case 20 times, > all passed, I double checked ILK and IVB platform, Both worked well. But I > don't know whether it's enough to judge this bug is fixed, because I see > yanbing describe that this issue is not stable reproduced. Yes, you are right mine is a separate test case, I can only guess that the root cause is the same. The next step would be to do Yanbing's original sequence with the patch applied.. (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > (In reply to comment #2) > > > > One way I can reproduce this on current nightly 100% on IVB if the console > > > > is blanked when I start the test: > > > > > > > > # echo 1 > /sys/class/graphics/fb0/blank > > > > # kms_flip --run-subtest wf_vblank-vs-modeset > > > > > > > > Could you yanbing try this too? > > > > > > Could you also try the patch attached to bug #60002? > > > > I apply this patch on -nightly top, then loop running this case 20 times, > > all passed, I double checked ILK and IVB platform, Both worked well. But I > > don't know whether it's enough to judge this bug is fixed, because I see > > yanbing describe that this issue is not stable reproduced. > > Yes, you are right mine is a separate test case, I can only guess that the > root cause is the same. > > The next step would be to do Yanbing's original sequence with the patch > applied.. I just according to yanbing's original sequence, and can't reproduce this bug, I have reproduced on -fixes latest kernel, and is easy to come up this issue. So I think probably this patch really worked, you can apply the patch ,and if our nightly can't catch the error for a period, then we can close this bug. (In reply to comment #6) > [...] > > > > Could you also try the patch attached to bug #60002? > [...] > I just according to yanbing's original sequence, and can't reproduce this > bug, I have reproduced on -fixes latest kernel, and is easy to come up this > issue. So I think probably this patch really worked, you can apply the patch > ,and if our nightly can't catch the error for a period, then we can close > this bug. Could you try -nightly with the latest i-g-t? It has the patch now, so things should work. (In reply to comment #7) > (In reply to comment #6) > > [...] > > > > > Could you also try the patch attached to bug #60002? > > [...] > > I just according to yanbing's original sequence, and can't reproduce this > > bug, I have reproduced on -fixes latest kernel, and is easy to come up this > > issue. So I think probably this patch really worked, you can apply the patch > > ,and if our nightly can't catch the error for a period, then we can close > > this bug. > > Could you try -nightly with the latest i-g-t? It has the patch now, so > things should work. Running the sub-case only, it's OK, but it failed in our nightly test. I think this case might also have some occasion failed. (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > [...] > > > > > > Could you also try the patch attached to bug #60002? > > > [...] > > > I just according to yanbing's original sequence, and can't reproduce this > > > bug, I have reproduced on -fixes latest kernel, and is easy to come up this > > > issue. So I think probably this patch really worked, you can apply the patch > > > ,and if our nightly can't catch the error for a period, then we can close > > > this bug. > > > > Could you try -nightly with the latest i-g-t? It has the patch now, so > > things should work. > > Running the sub-case only, it's OK, but it failed in our nightly test. I > think this case might also have some occasion failed. Ok, I couldn't yet reproduce it. Based on what you say, it's perhaps affected by a preceding test. Do you have some log with the sequence of tests for the failing case? Does it fail with the original error message? Would be great to have an updated dmesg too with the failure. Can you please retest with the following patch applied to latest -nightly? https://patchwork.kernel.org/patch/2709081/ (In reply to comment #10) > Can you please retest with the following patch applied to latest -nightly? > > https://patchwork.kernel.org/patch/2709081/ Test with nightly kernel, this case worked well, and I find during a long time this case haven't failed, I think it's more stable, and we can close it now. (In reply to comment #11) > (In reply to comment #10) > > Can you please retest with the following patch applied to latest -nightly? > > > > https://patchwork.kernel.org/patch/2709081/ > > Test with nightly kernel, this case worked well, and I find during a long > time this case haven't failed, I think it's more stable, and we can close it > now. I mean during a long time nightly testing, this case all passed. Nice, I guess we can close this without more work! Thanks for the update. Closing verified+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.