| Summary: | [SNB regression]*ERROR* mismatch in adjusted_mode.flags | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | cancan,feng <cancan.feng> | ||||||||
| Component: | DRM/Intel | Assignee: | 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
cancan,feng
2013-07-02 01:33:26 UTC
Created attachment 81841 [details]
complete dmesg info after booting up
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. 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 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 (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. Created attachment 81917 [details]
dmesg info on kernel commit 510d5f
I've been ignoring this whilst the pipe checker was in flux, do you mind confirming if the bug is still present? 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. (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. (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. *** This bug has been marked as a duplicate of bug 65442 *** 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.