Summary: | [HSW IVB ILK SNB bisected] I-G-T/testdisplay -f cause "*ERROR* mismatch in adjusted_mode.flags" | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | cancan,feng <cancan.feng> | ||||||||
Component: | DRM/Intel | Assignee: | Imre Deak <imre.deak> | ||||||||
Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||
Severity: | major | ||||||||||
Priority: | medium | CC: | cancan.feng, gordon.jin, guang.a.yang, s_j_newbury, yangweix.shui | ||||||||
Version: | unspecified | ||||||||||
Hardware: | Other | ||||||||||
OS: | All | ||||||||||
Whiteboard: | |||||||||||
i915 platform: | i915 features: | ||||||||||
Attachments: |
|
Description
cancan,feng
2013-06-06 07:17:18 UTC
Created attachment 80383 [details]
testdisplay -f calltrace
Jesse? Let's restrict this bug to adjusted_mode.flags mismatches on Haswell. Feng Cancan can you please file new bug reports (and link to this one here) if we still have adjusted_mode.flags mismatches on other architectures on latest -nightly? There's been one other report for ivb, bug #65287 (In reply to comment #3) > Let's restrict this bug to adjusted_mode.flags mismatches on Haswell. > > Feng Cancan can you please file new bug reports (and link to this one here) > if we still have adjusted_mode.flags mismatches on other architectures on > latest -nightly? > > There's been one other report for ivb, bug #65287 I find this adjusted_mode.flags mismatches ERROR also happens on SNB platform on latest -nightly, so I filed a new bug to track this, bug #66480. (In reply to comment #3) > Let's restrict this bug to adjusted_mode.flags mismatches on Haswell. > > Feng Cancan can you please file new bug reports (and link to this one here) > if we still have adjusted_mode.flags mismatches on other architectures on > latest -nightly? This issue happens on HSW, SNB, IVB, ILK. We already have this bug to track HSW, and I just filed a new bug #66480 to track SNB, do you think we need two new bugs to track this issue respectively for IVB and ILK? > > There's been one other report for ivb, bug #65287 Hmm, I find adjusted_mode.flags mismatches in bug #65287 is caused by DP pipe, but adjusted_mode.flags mismatches in this bug is caused by setting up customized timing..So I don't think they are same issues. This bug is not the same with "Bug 65287 *ERROR* mismatch in adjusted_mode.flags (expected 1, found 0)". I find it exists during machine boot up with the culprit kernels. But cancan's bug is caused by "testdisplay -f", and it also reproduceable on latest -nightly kernel. I modified the bug title here. This bug is not the same with "Bug 65287 *ERROR* mismatch in adjusted_mode.flags (expected 1, found 0)". I find it exists during machine boot up with the culprit kernels. But cancan's bug is caused by "testdisplay -f", and it also reproduceable on latest -nightly kernel. I modified the bug title here. Still present? Created attachment 82794 [details] dmesg: call trace also exist. (In reply to comment #8) > Still present? Yes, it's also reproducible on latest -next-queued. (In reply to comment #9) > Created attachment 82794 [details] > dmesg: call trace also exist. > > (In reply to comment #8) > > Still present? > > Yes, it's also reproducible on latest -next-queued. Again, when retesting to check whether we've fixed a bug please use drm-intel-nightly branch. (In reply to comment #10) > (In reply to comment #9) > > Created attachment 82794 [details] > > dmesg: call trace also exist. > > > > (In reply to comment #8) > > > Still present? > > > > Yes, it's also reproducible on latest -next-queued. > > Again, when retesting to check whether we've fixed a bug please use > drm-intel-nightly branch. On latest -nightly, this issue also be reproduced. *** Bug 66480 has been marked as a duplicate of this bug. *** Created attachment 82997 [details] [review] sanitize requested sync polarity flags This seems to be caused by testdisplay requesting a mode without either negative or positive polarity (mode.flags=0). All intel encoders treat this to mean negative polarity. The mode state readout/checker code otoh expects exactly one of the polarity bits to bet set. The attached patch is one way to fix this, could you give it a go? (In reply to comment #13) > Created attachment 82997 [details] [review] [review] > sanitize requested sync polarity flags > > This seems to be caused by testdisplay requesting a mode without either > negative or positive polarity (mode.flags=0). All intel encoders treat this > to mean negative polarity. The mode state readout/checker code otoh expects > exactly one of the polarity bits to bet set. The attached patch is one way > to fix this, could you give it a go? I tested this patch on drm-intel-nightly branch, this issue has gone. So I think we could close this bug. Fix merged to dinq: commit 775e18a9561725e07ea68ada82880013e7b70cb7 Author: Imre Deak <imre.deak@intel.com> Date: Tue Jul 30 13:36:32 2013 +0300 drm/i915: make user mode sync polarity setting explicit I'm hitting something very similar on Crestline: [drm:intel_pipe_config_compare] *ERROR* mismatch in adjusted_mode.clock (expected 108000, found 0) [ 2531.618873] ------------[ cut here ]------------ [ 2531.618908] WARNING: CPU: 0 PID: 1632 at drivers/gpu/drm/i915/intel_display.c:8959 check_crtc_state+0x7b4/0x83a [i915]() [ 2531.618909] pipe state doesn't match! I'm going to test the latest drm-intel-nightly and report back. (In reply to comment #17) > I'm going to test the latest drm-intel-nightly and report back. Still occurs with latest drm-intel-nightly. (In reply to comment #16) > I'm hitting something very similar on Crestline: > > [drm:intel_pipe_config_compare] *ERROR* mismatch in adjusted_mode.clock > (expected 108000, found 0) > [ 2531.618873] ------------[ cut here ]------------ > [ 2531.618908] WARNING: CPU: 0 PID: 1632 at > drivers/gpu/drm/i915/intel_display.c:8959 check_crtc_state+0x7b4/0x83a > [i915]() > [ 2531.618909] pipe state doesn't match! That's totally different kind of machine, and a different error message. File a new bug please, and include the full dmesg with drm.debug=6. Closing old 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.