Bug 65442 - [HSW IVB ILK SNB bisected] I-G-T/testdisplay -f cause "*ERROR* mismatch in adjusted_mode.flags"
Summary: [HSW IVB ILK SNB bisected] I-G-T/testdisplay -f cause "*ERROR* mismatch in ad...
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium major
Assignee: Imre Deak
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
: 66480 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-06-06 07:17 UTC by cancan,feng
Modified: 2017-09-04 10:13 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:

Attachments
testdisplay -f calltrace (23.42 KB, text/plain)
2013-06-06 07:18 UTC, cancan,feng 		no flags Details
dmesg: call trace also exist. (2.42 KB, text/plain)
2013-07-22 01:50 UTC, shui yangwei 		no flags Details
sanitize requested sync polarity flags (1.43 KB, patch)
2013-07-25 13:09 UTC, Imre Deak 		no flags Details | Splinter Review
View All

Description cancan,feng 2013-06-06 07:17:18 UTC 
System Environment:
--------------------------------------------
Kernel: (drm-intel-next-queued)d7697eea3eec74c561d12887d892c53ac4380c00
Some additional commit info:
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Jun 2 17:23:01 2013 +0200

    drm/i915: optimize vblank waits in set_base_atomic

Bug detail Description:
--------------------------------------------
I-G-T testdisplay causes call trace while setting up customized timing. This issue happens on HSW, IVB, SNB, ILK. 
[   32.373406] Call Trace:
[   32.373427]  [<ffffffff816de142>] ? dump_stack+0xd/0x17
[   32.373461]  [<ffffffff8102c67d>] ? warn_slowpath_common+0x5f/0x77
[   32.373498]  [<ffffffff8102c72d>] ? warn_slowpath_fmt+0x45/0x4a
[   32.373539]  [<ffffffffa0088edd>] ? intel_modeset_check_state+0x904/0x94b [i915]
[   32.373587]  [<ffffffffa0088f94>] ? intel_set_mode+0x1d/0x27 [i915]
[   32.373635]  [<ffffffffa0089521>] ? intel_crtc_set_config+0x583/0x73b [i915]
[   32.373688]  [<ffffffffa0013cc1>] ? drm_mode_set_config_internal+0x19/0x40 [drm]
[   32.373751]  [<ffffffffa0015925>] ? drm_mode_setcrtc+0x437/0x4e8 [drm]
[   32.373812]  [<ffffffffa000946c>] ? drm_ioctl+0x290/0x3b5 [drm]
[   32.373862]  [<ffffffffa00154ee>] ? drm_mode_setplane+0x30f/0x30f [drm]
[   32.373901]  [<ffffffff816e1b31>] ? __schedule+0x60a/0x751
[   32.373935]  [<ffffffff8104b125>] ? __wake_up+0x35/0x46
[   32.373968]  [<ffffffff810dc342>] ? vfs_ioctl+0x1e/0x31
[   32.373999]  [<ffffffff810dcb71>] ? do_vfs_ioctl+0x3e9/0x42b
[   32.374033]  [<ffffffff810dcc01>] ? SyS_ioctl+0x4e/0x7d
[   32.374065]  [<ffffffff816e7e12>] ? system_call_fastpath+0x16/0x1b
[   32.374101] ---[ end trace ee545d65293e034b ]---

I attach the whole dmesg info in the attachment, and this is a regression, here is the bisect info:

Bisect result:
--------------------------------------------
045ac3b5629d9711531a408e92f9074db6afe7ce is the first bad commit
commit 045ac3b5629d9711531a408e92f9074db6afe7ce
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Tue May 14 17:08:26 2013 -0700

    drm/i915: add encoder get_config function v5

    We can use this for fetching encoder specific pipe_config state, like
    mode flags, adjusted clock, etc.

    Just used for mode flags atm, so we can check the pipe config state at
    mode set time.

    v2: get_config when checking hw state too
    v3: fix DVO and LVDS mode flags (Ville)
        get SDVO DTD for flag fetch (Ville)
    v4: use input timings (Ville)
        correct command used (Ville)
        remove gen4 check (Ville)
    v5: get DDI flag config too

    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v4)
    Tested-by: Paulo Zanoni <przanoni@gmail.com> (the new hsw ddi stuff)
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

:040000 040000 b2b8a7612a37028fb4ff2f62e372b70e9ce5179a 7b4bf7d42a2d1ce673ea2f405035e4c9c7dfe4a8 

M      drivers

Reproduce step:
--------------------------------------------
1. booting up machine
2. ./testdisplay -f 38.25,800,832,912,1024,600,603,607,624(or other)
3. dmesg | grep "Call Trace"
Comment 1 cancan,feng 2013-06-06 07:18:20 UTC 
Created attachment 80383 [details]
testdisplay -f calltrace
Comment 2 Daniel Vetter 2013-06-16 11:53:21 UTC 
Jesse?
Comment 3 Daniel Vetter 2013-07-01 16:29:42 UTC 
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
Comment 4 cancan,feng 2013-07-02 01:40:19 UTC 
(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.
Comment 5 cancan,feng 2013-07-02 02:16:50 UTC 
(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.
Comment 6 shui yangwei 2013-07-02 02:34:02 UTC 
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.
Comment 7 shui yangwei 2013-07-02 02:34:17 UTC 
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.
Comment 8 Chris Wilson 2013-07-20 14:49:42 UTC 
Still present?
Comment 9 shui yangwei 2013-07-22 01:50:03 UTC 
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.
Comment 10 Daniel Vetter 2013-07-22 06:01:03 UTC 
(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.
Comment 11 shui yangwei 2013-07-22 06:30:25 UTC 
(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.
Comment 12 Chris Wilson 2013-07-22 12:29:13 UTC 
*** Bug 66480 has been marked as a duplicate of this bug. ***
Comment 13 Imre Deak 2013-07-25 13:09:14 UTC 
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?
Comment 14 cancan,feng 2013-07-29 03:31:21 UTC 
(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.
Comment 15 Daniel Vetter 2013-08-05 06:15:40 UTC 
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
Comment 16 Steven Newbury 2013-10-02 14:09:31 UTC 
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!
Comment 17 Steven Newbury 2013-10-02 14:11:01 UTC 
I'm going to test the latest drm-intel-nightly and report back.
Comment 18 Steven Newbury 2013-10-02 15:06:13 UTC 
(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.
Comment 19 Ville Syrjala 2013-10-02 19:18:56 UTC 
(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.
Comment 20 Jari Tahvanainen 2017-09-04 10:13:32 UTC 
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.