Bug 66480

Summary: [SNB regression]*ERROR* mismatch in adjusted_mode.flags
Product: DRI Reporter: cancan,feng <cancan.feng>
Component: DRM/IntelAssignee: shui yangwei <yangweix.shui>
Status: CLOSED DUPLICATE QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: major    
Priority: medium CC: cancan.feng, gordon.jin, guang.a.yang
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
complete dmesg info after booting up
none
dmesg info on kernel commit 510d5f
none
dmesg: Error also exist after execute testdisplay -f none

Description cancan,feng 2013-07-02 01:33:26 UTC
System Environment:
--------------------------------------------
Kernel: (drm-intel-next-queued)b110d88135c7aa43022c8f083079ba0e15737cc8
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Wed Jun 26 01:38:19 2013 +0300

    drm/i915: flip on a no fb -> fb transition if crtc is active v3

Bug detail Description:
--------------------------------------------
I-G-T testdisplay causes call trace while setting up customized timing. On SNB platform also has *ERROR* mismatch in clock and Call Trace in dmesg, but here we restrict this bug to adjusted_mode.flags mismatches. 

[   59.304657] [drm:intel_pipe_config_compare] *ERROR* mismatch in adjusted_mode.flags (expected 0, found 2)

But for prudential reasons, I will attach the complete dmesg info in the attachment.

Reproduce Steps:
---------------------------------------------
1.booting up machine
2../testdisplay -f 38.25,800,832,912,1024,600,603,607,624
3.dmesg | grep "ERROR"
Comment 1 cancan,feng 2013-07-02 01:36:40 UTC
Created attachment 81841 [details]
complete dmesg info after booting up
Comment 2 Daniel Vetter 2013-07-02 07:23:00 UTC
Can you please bisect where this has been introduced? I've looked at the dmesg and the hw state we read out looks rather strange ...

[    0.930732] [drm:intel_dump_pipe_config], [CRTC:3][setup_hw_state] config for pipe A
[    0.930733] [drm:intel_dump_pipe_config], cpu_transcoder: A
[    0.930735] [drm:intel_dump_pipe_config], pipe bpp: 0, dithering: 0
[    0.930736] [drm:intel_dump_pipe_config], fdi/pch: 1, lanes: 4, gmch_m: 586736, gmch_n: 8388608, link_m: 48894, link_n: 524288, tu: 64
[    0.930738] [drm:intel_dump_pipe_config], requested mode:
[    0.930740] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 720 0 0 0 400 0 0 0 0x0 0x0
[    0.930742] [drm:intel_dump_pipe_config], adjusted mode:
[    0.930743] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 25179 0 0 0 0 0 0 0 0 0x0 0xa
[    0.930746] [drm:intel_dump_pipe_config], gmch pfit: control: 0x00000000, ratios: 0x00000000, lvds border: 0x00000000
[    0.930747] [drm:intel_dump_pipe_config], pch pfit: pos: 0x00000000, size: 0x028001e0
[    0.930749] [drm:intel_dump_pipe_config], ips: 0

The adjusted mode especially is rather bogus.
Comment 3 cancan,feng 2013-07-02 09:27:22 UTC
I bisected this issue on SNB, it turns out the same first bad commit with bug #65442. Bisect info as following:

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
Comment 4 Daniel Vetter 2013-07-02 09:55:18 UTC
Hm, the bogus adjusted_mode readout could be due to Jesse's bug in the hw state readout code. Can you please retest with

commit 510d5f2f6b97eccbfa08234e21b0577c1748807d
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Mon Jul 1 15:50:17 2013 -0700

    drm/i915: split encoder get_config calls from crtc get_clock calls
Comment 5 cancan,feng 2013-07-03 01:50:21 UTC
(In reply to comment #4)
> Hm, the bogus adjusted_mode readout could be due to Jesse's bug in the hw
> state readout code. Can you please retest with
> 
> commit 510d5f2f6b97eccbfa08234e21b0577c1748807d
> Author: Jesse Barnes <jbarnes@virtuousgeek.org>
> Date:   Mon Jul 1 15:50:17 2013 -0700
> 
>     drm/i915: split encoder get_config calls from crtc get_clock calls

I tested this commit, but it also has "*ERROR* mismatch in adjusted_mode.flags". I will attach the dmesg info.
Comment 6 cancan,feng 2013-07-03 01:53:13 UTC
Created attachment 81917 [details]
dmesg info on kernel commit 510d5f
Comment 7 Chris Wilson 2013-07-20 14:48:27 UTC
I've been ignoring this whilst the pipe checker was in flux, do you mind confirming if the bug is still present?
Comment 8 shui yangwei 2013-07-22 01:52:39 UTC
Created attachment 82795 [details]
dmesg: Error also exist after execute testdisplay -f

(In reply to comment #7)
> I've been ignoring this whilst the pipe checker was in flux, do you mind
> confirming if the bug is still present?

It's also exist on latest -next-queued.
Comment 9 Daniel Vetter 2013-07-22 05:59:18 UTC
(In reply to comment #8)
> Created attachment 82795 [details]
> dmesg: Error also exist after execute testdisplay -f
> 
> (In reply to comment #7)
> > I've been ignoring this whilst the pipe checker was in flux, do you mind
> > confirming if the bug is still present?
> 
> It's also exist on latest -next-queued.

Please always retest drm-intel-nightly, otherwise you might miss important bugfixes from drm-intel-fixes (or one of the drm branches) if you only test dinq. Please retest.
Comment 10 shui yangwei 2013-07-22 06:30:12 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > Created attachment 82795 [details]
> > dmesg: Error also exist after execute testdisplay -f
> > 
> > (In reply to comment #7)
> > > I've been ignoring this whilst the pipe checker was in flux, do you mind
> > > confirming if the bug is still present?
> > 
> > It's also exist on latest -next-queued.
> 
> Please always retest drm-intel-nightly, otherwise you might miss important
> bugfixes from drm-intel-fixes (or one of the drm branches) if you only test
> dinq. Please retest.

On latest -nightly, this issue also be reproduced.
Comment 11 Chris Wilson 2013-07-22 12:29:13 UTC

*** This bug has been marked as a duplicate of bug 65442 ***
Comment 12 Jari Tahvanainen 2017-09-04 10:14:18 UTC
Closing old verified+duplicate as duplicate of closed+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.