| Summary: | [IVB]kms_flip error: inter-vblank ts jitter VGA output | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| 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-29 03:18:17 UTC
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.