Created attachment 73629 [details] wf_vblank-vs-modeset-fail.dmesg Environment: -------------------- Kernel: (drm-intel-nightly)60cc7310cee5696ada10919578195d1605c05f61 Some additional commit info: Merge: 305928b 735dc0d Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Jan 23 17:57:14 2013 +0100 Description: -------------------- Using the latest -nightly 1. /GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests/kms_flip --run-subtest wf_vblank-vs-modeset 2.$?=4 3. STD-OUT: Using monotonic timestamps running testcase: wf_vblank-vs-modeset Beginning wf_vblank-vs-modeset on crtc 3, connector 7 1280x1024 60 1280 1328 1440 1688 1024 1025 1028 1066 0x5 0x48 108000 failed to page flip: Invalid argument 4.This phenomenon is very strange.Because it's not be reproduced every time.But I found some regularity: (1)When booting ILK and standing after a time (maybe some minutes or hours),it's to likely be reproduced. (2)When this happend,running this subcase at the next time or more,this phenomenon can not be reproduced anymore. 5.I attached the dmesg.
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.