Created attachment 73803 [details] inter-vblank-IVB.dmesg Environment(64 bit): -------------------- Kernel: (drm-intel-nightly)5e94786cd18121acb51cf75478b3bf9eec56c26c Some additional commit info: Merge: b286e36 735dc0d Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Jan 28 00:29:10 2013 +0100 Description: -------------------- Using the latest -nightly 1.Running some kms_flip subcases fail and there are same std out by "inter-vblank ts jitter". 2.std out: Using monotonic timestamps running testcase: blocking-wf_vblank Beginning blocking-wf_vblank on crtc 3, connector 9 1680x1050 60 1680 1784 1960 2240 1050 1053 1059 1089 0x6 0x48 146250 .....................................................inter-vblank ts jitter: 0s, 16583us 3.Fail like this ,subcase list on IVB: (1)blocking-wf_vblank (2)wf_vblank-ts-check 4.I attached the dmesg.
Hm, this one is very funny, the test complains about a 16ms interframe time, which is what I'd expect for a 60 Hz display. I'm totally confused here ... Does this happen only on this specific machine/display combination or also on others? And can you please attach the xrandr --verbose output of this configuration for reference.
(In reply to comment #1) > Hm, this one is very funny, the test complains about a 16ms interframe time, > which is what I'd expect for a 60 Hz display. I'm totally confused here ... > > Does this happen only on this specific machine/display combination or also > on others? > > And can you please attach the xrandr --verbose output of this configuration > for reference. 1. I attached the xrandr.txt first. 2. And I will give other results in future.
Created attachment 73812 [details] xrandr.txt
I've let my ivb loop over this test for a few hours, the only failure I've seen is: vblank ts before the vblank was issued! timerdiff -2635s, 292857us Which is even less reassuring than what you've found.
(In reply to comment #4) > I've let my ivb loop over this test for a few hours, the only failure I've > seen is: > > vblank ts before the vblank was issued! > timerdiff -2635s, 292857us > > Which is even less reassuring than what you've found. As same as the bug 59999 on ivb.When I removed the VGA monitor ,both of them pass. Once connecting with VGA ,both of them fail by this std out.
(In reply to comment #5) > As same as the bug 59999 on ivb.When I removed the VGA monitor ,both of them > pass. > Once connecting with VGA ,both of them fail by this std out. It's slightly different from that bug, as that I've managed to hit a really big _negative_ timestamp difference. That should be impossible, this behaviour you're seeing here is only buggy ;-) Since it seems to be related to VGA: Can you please test with drm_kms_helper.poll=0 on the kernel cmdline?
(In reply to comment #6) > (In reply to comment #5) > > As same as the bug 59999 on ivb.When I removed the VGA monitor ,both of them > > pass. > > Once connecting with VGA ,both of them fail by this std out. > > It's slightly different from that bug, as that I've managed to hit a really > big _negative_ timestamp difference. That should be impossible, this > behaviour you're seeing here is only buggy ;-) > > Since it seems to be related to VGA: Can you please test with > drm_kms_helper.poll=0 on the kernel cmdline? I had test with drm_kms_helper.poll=0 but it seems useless.The result is same as before.Connecting VGA was fail but removing it was pass.
Can you please retest with the following patch applied to latest -nightly? https://patchwork.kernel.org/patch/2709081/
(In reply to comment #8) > Can you please retest with the following patch applied to latest -nightly? > > https://patchwork.kernel.org/patch/2709081/ Test with latest nightly kernel by using VGA pipe, this case worked well, and I checked nightly tests, the subcase "blocking-wf_vblank" passed for a period times. I think we can close it now.
Odd. As discussed on irc, that patch shouldn't have mattered, so we have no reason explanation for the failure and subsequent success. Oh well something to worry about next time this fails, until then...
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.