Created attachment 87310 [details] environment info, kernel log, intel reg, bios info, Xorg info 1. The DP display function(for IT6506 receiver and IT6505 transmitter) is working with i915/kernel 3.9.5 but failed with i915/kernel 3.1x. 2. It seems having to do with intel_dp.c (it works if I replace intel_dp.c/kernel 3.1x with intel_dp.c/kernel 3.9.5)
The issue happened on Intel Haswell platform (Q87) but was not seen on Intel IvyBridge platform.
A few test requests: - Does reverting b90f517627f76640e0f6d2aa17f143dc10623a58 fix the issue? If not please try to bisect which commit exactly introduced the regression. Since you already figured out that it's something in intel_dp.c you can restrict the bisect like this git bisect start v3.10 v3.9 -- drivers/gpu/drm/i915/intel_dp.c (Assuming v3.10 is the first bad version) - Please retest on latest drm-intel-nightly git trees, we have a fix there which might be relevant. - Please attach the .config for your kernel built (as a plain text file, zip is a hassle to handle).
Created attachment 87425 [details] used in Fedora kernel 3.11.1-200.fc18.i686 and used for self-compiled kernel 3.12.0-rc4 1. Please find the kernel config file that I attached to this thread 2. The bug seems to be gone with the kernel files built from drm-intel-nightly (tested in Fedora 19) [test@localhost drm-intel]$ git branch -a * drm-intel-nightly drm-intel-testing for-linux-next remotes/origin/HEAD -> origin/drm-intel-testing remotes/origin/drm-intel-fixes remotes/origin/drm-intel-next remotes/origin/drm-intel-next-queued remotes/origin/drm-intel-nightly remotes/origin/drm-intel-testing remotes/origin/for-linux-next remotes/origin/for-linux-next-fixes remotes/origin/rerere-cache [test@localhost drm-intel]$ git log commit 7ac92d2b6b9dec3585b35a80631f7b56e8e381d0 Merge: 5d4efa4 d778b6b Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Oct 9 09:21:25 2013 +0200 Merge remote-tracking branch 'origin/drm-intel-fixes' into drm-intel-nightly Conflicts: drivers/gpu/drm/i915/intel_dp.c
Ken, I'm glad to hear it works with drm-intel-nightly, but we need to know what fixed the problem, so we can backport the fix to stable kernels as necessary. Please do a *reverse* git bisect to find the commit that introduced the fix to the issue. http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/ http://stackoverflow.com/questions/15407075/how-could-i-use-git-bisect-to-find-the-first-good-commit
Created attachment 87577 [details] git bisect log info - intel_dp.c/v3.9.5-v3.10.10 1. The total commits regarding intel_dp.c between v3.9.5 and v3.10.10 are about 44 records (see git_bisect_v3.9.5_v3.10.10_intel_dp.log that I attached to this thread) 2. Please advise if you have any suggestions to improve the trial and error process. git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git cd linux-stable git bisect --start drivers/gpu/drm/i915/intel_dp.c git bisect bad v3.10.10 git bisect good v3.9.5 git bisect view --stat > git_bisect_v3.9.5_v3.10.10_intel_dp.log cat git_bisect_v3.10.10_intel_dp.log | grep 'Author' | wc -l
(In reply to comment #5) > Created attachment 87577 [details] > git bisect log info - intel_dp.c/v3.9.5-v3.10.10 > > 1. The total commits regarding intel_dp.c between v3.9.5 and v3.10.10 are > about 44 records (see git_bisect_v3.9.5_v3.10.10_intel_dp.log that I > attached to this thread) > 2. Please advise if you have any suggestions to improve the trial and error > process. git bisect won't let you test all 44 commits, but it uses a binary search on the history, so should only be about 5-6 revsisions for testing. That's the reason why bisecting of entire kernel releases (with a few 10k commits) is possible, but restricting the search space to specific files like here always helps. git will also tell you how many steps are left after each testing round.
Created attachment 87580 [details] git bisect first bad commit info - intel_dp.c/v3.9.5-v3.10.10 Please check the 1st bad commit info I got git bisect view --stat | tee -a git_bisect_v3.9.5_v3.10.10_intel_dp_first_bad_commit.log commit 2c55c336a71cb32ae837dc829d216dc86ed9d84f Author: Jani Nikula <jani.nikula@intel.com> Date: Tue Apr 9 08:11:00 2013 +0300 drm/i915: use lower aux clock divider on non-ULT HSW Workaround to avoid intermittent aux channel failures, per spec change. v2: Don't mess with cpu dp aux divider (Paulo Zanoni) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Kill spurious tab spotted by Paulo.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> drivers/gpu/drm/i915/intel_dp.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
Please try v3.12-rc4 which should have commit bc86625a4ff7574d4d4dba79723457711eb784e0 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Jul 21 16:00:03 2013 +0100 drm/i915: Retry DP aux_ch communications with a different clock after failur which changes the divider and adds a retry with another divider.
Created attachment 87584 [details] kernel log with drm_debug info for bc86625a4ff7574d4d4dba79723457711eb784e0
(In reply to comment #8) > Please try v3.12-rc4 which should have > > commit bc86625a4ff7574d4d4dba79723457711eb784e0 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Sun Jul 21 16:00:03 2013 +0100 > > drm/i915: Retry DP aux_ch communications with a different clock after > failur > > which changes the divider and adds a retry with another divider. 1. The DP display issue(which may have to do with aux timeout) was gone with commit bc86625a4ff7574d4d4dba79723457711eb784e0 (please see the kernel log that I attached to this thread). 2. The DP display issue still exists in the commit prior to commit bc86625a4ff7574d4d4dba79723457711eb784e0. 3. The DP audio issue exists in commit bc86625a4ff7574d4d4dba79723457711eb784e0 (no card codec interface was found in /proc/asound/)
Created attachment 87587 [details] alsa-info log- bc86625a4ff7574d4d4dba79723457711eb784e0 Please find the alsa-info log that I attached to this thread for the DP audio issue (in commit bc86625a4ff7574d4d4dba79723457711eb784e0)
(In reply to comment #10) > (In reply to comment #8) > > Please try v3.12-rc4 which should have > > > > commit bc86625a4ff7574d4d4dba79723457711eb784e0 > > Author: Chris Wilson <chris@chris-wilson.co.uk> > > Date: Sun Jul 21 16:00:03 2013 +0100 > > > > drm/i915: Retry DP aux_ch communications with a different clock after > > failur > > > > which changes the divider and adds a retry with another divider. > > 1. The DP display issue(which may have to do with aux timeout) was gone with > commit bc86625a4ff7574d4d4dba79723457711eb784e0 (please see the kernel log > that I attached to this thread). > > 2. The DP display issue still exists in the commit prior to commit > bc86625a4ff7574d4d4dba79723457711eb784e0. Daniel, we need to consider backporting Chris' fix to stable kernels. > 3. The DP audio issue exists in commit > bc86625a4ff7574d4d4dba79723457711eb784e0 (no card codec interface was found > in /proc/asound/) From the logs: [ 8.878426] ALSA sound/pci/hda/hda_intel.c:3807 Haswell must build in CONFIG_SND_HDA_I915 [ 8.878428] ALSA sound/pci/hda/hda_intel.c:3836 Error request power-well from i915 Do you have CONFIG_SND_HDA_I915=y instead of =m? Also, I'm confused by your dmesg in comment #9 having "Linux version 3.11.0-rc2+" and the line numbers above match that kernel version. Were you running some frankenstein combination of 3.11-rc2 and 3.12-rc4 or what?
(In reply to comment #12) > (In reply to comment #10) > > (In reply to comment #8) > > > Please try v3.12-rc4 which should have > > > > > > commit bc86625a4ff7574d4d4dba79723457711eb784e0 > > > Author: Chris Wilson <chris@chris-wilson.co.uk> > > > Date: Sun Jul 21 16:00:03 2013 +0100 > > > > > > drm/i915: Retry DP aux_ch communications with a different clock after > > > failur > > > > > > which changes the divider and adds a retry with another divider. > > > > 1. The DP display issue(which may have to do with aux timeout) was gone with > > commit bc86625a4ff7574d4d4dba79723457711eb784e0 (please see the kernel log > > that I attached to this thread). > > > > 2. The DP display issue still exists in the commit prior to commit > > bc86625a4ff7574d4d4dba79723457711eb784e0. > > Daniel, we need to consider backporting Chris' fix to stable kernels. > > > 3. The DP audio issue exists in commit > > bc86625a4ff7574d4d4dba79723457711eb784e0 (no card codec interface was found > > in /proc/asound/) > > From the logs: > > [ 8.878426] ALSA sound/pci/hda/hda_intel.c:3807 Haswell must build in > CONFIG_SND_HDA_I915 > [ 8.878428] ALSA sound/pci/hda/hda_intel.c:3836 Error request power-well > from i915 > > Do you have CONFIG_SND_HDA_I915=y instead of =m? > => Sorry, tt might be my mistake to use the incorrect kernel configuration. I will update it later. > Also, I'm confused by your dmesg in comment #9 having "Linux version > 3.11.0-rc2+" and the line numbers above match that kernel version. Were you > running some frankenstein combination of 3.11-rc2 and 3.12-rc4 or what? => I used git reset --hard bc86625a4ff7574d4d4dba79723457711eb784e0 (VERSION = 3, PATCHLEVEL = 11, SUBLEVEL = 0 EXTRAVERSION = -rc2 in Makefile)
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #10) > > > (In reply to comment #8) > > > > Please try v3.12-rc4 which should have > > > > > > > > commit bc86625a4ff7574d4d4dba79723457711eb784e0 > > > > Author: Chris Wilson <chris@chris-wilson.co.uk> > > > > Date: Sun Jul 21 16:00:03 2013 +0100 > > > > > > > > drm/i915: Retry DP aux_ch communications with a different clock after > > > > failur > > > > > > > > which changes the divider and adds a retry with another divider. > > > > > > 1. The DP display issue(which may have to do with aux timeout) was gone with > > > commit bc86625a4ff7574d4d4dba79723457711eb784e0 (please see the kernel log > > > that I attached to this thread). > > > > > > 2. The DP display issue still exists in the commit prior to commit > > > bc86625a4ff7574d4d4dba79723457711eb784e0. > > > > Daniel, we need to consider backporting Chris' fix to stable kernels. > > > > > 3. The DP audio issue exists in commit > > > bc86625a4ff7574d4d4dba79723457711eb784e0 (no card codec interface was found > > > in /proc/asound/) > > > > From the logs: > > > > [ 8.878426] ALSA sound/pci/hda/hda_intel.c:3807 Haswell must build in > > CONFIG_SND_HDA_I915 > > [ 8.878428] ALSA sound/pci/hda/hda_intel.c:3836 Error request power-well > > from i915 > > > > Do you have CONFIG_SND_HDA_I915=y instead of =m? > > > > => Sorry, tt might be my mistake to use the incorrect kernel configuration. > I will update it later. > > > > Also, I'm confused by your dmesg in comment #9 having "Linux version > > 3.11.0-rc2+" and the line numbers above match that kernel version. Were you > > running some frankenstein combination of 3.11-rc2 and 3.12-rc4 or what? > > => I used git reset --hard bc86625a4ff7574d4d4dba79723457711eb784e0 (VERSION > = 3, PATCHLEVEL = 11, SUBLEVEL = 0 EXTRAVERSION = -rc2 in Makefile) That doesn't do what you think it does. Use git checkout.
Created attachment 87638 [details] kernel log with drm_debug info using checkout bc86625a4ff7574d4d4dba79723457711eb784e0
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > (In reply to comment #10) > > > > (In reply to comment #8) > > > > > Please try v3.12-rc4 which should have > > > > > > > > > > commit bc86625a4ff7574d4d4dba79723457711eb784e0 > > > > > Author: Chris Wilson <chris@chris-wilson.co.uk> > > > > > Date: Sun Jul 21 16:00:03 2013 +0100 > > > > > > > > > > drm/i915: Retry DP aux_ch communications with a different clock after > > > > > failur > > > > > > > > > > which changes the divider and adds a retry with another divider. > > > > > > > > 1. The DP display issue(which may have to do with aux timeout) was gone with > > > > commit bc86625a4ff7574d4d4dba79723457711eb784e0 (please see the kernel log > > > > that I attached to this thread). > > > > > > > > 2. The DP display issue still exists in the commit prior to commit > > > > bc86625a4ff7574d4d4dba79723457711eb784e0. > > > > > > Daniel, we need to consider backporting Chris' fix to stable kernels. > > > > > > > 3. The DP audio issue exists in commit > > > > bc86625a4ff7574d4d4dba79723457711eb784e0 (no card codec interface was found > > > > in /proc/asound/) > > > > > > From the logs: > > > > > > [ 8.878426] ALSA sound/pci/hda/hda_intel.c:3807 Haswell must build in > > > CONFIG_SND_HDA_I915 > > > [ 8.878428] ALSA sound/pci/hda/hda_intel.c:3836 Error request power-well > > > from i915 > > > > > > Do you have CONFIG_SND_HDA_I915=y instead of =m? > > > > > > > => Sorry, tt might be my mistake to use the incorrect kernel configuration. > > I will update it later. > > > > > > > Also, I'm confused by your dmesg in comment #9 having "Linux version > > > 3.11.0-rc2+" and the line numbers above match that kernel version. Were you > > > running some frankenstein combination of 3.11-rc2 and 3.12-rc4 or what? > > > > => I used git reset --hard bc86625a4ff7574d4d4dba79723457711eb784e0 (VERSION > > = 3, PATCHLEVEL = 11, SUBLEVEL = 0 EXTRAVERSION = -rc2 in Makefile) > > That doesn't do what you think it does. Use git checkout. 1. The kernel version would be 3.11.0-rc2 (referring to VERSION =3, PATCHLEVEL = 11 SUBLEVEL = 0, EXTRAVERSION = -rc2 in Makefile) when I used git git checkout bc86625a4ff7574d4d4dba79723457711eb784e0 2. The DP display/audio functions are working with this commit bc86625a4ff7574d4d4dba79723457711eb784e0 (please check the attachment 87638 [details] for the kernel log info; the audio issue was gone if I used the correct kernel config)
Ok, I've submitted the stable backport request for commit bc86625a4ff7574d4d4dba79723457711eb784e0 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Jul 21 16:00:03 2013 +0100 drm/i915: Retry DP aux_ch communications with a different clock after failure so I think we're good. Thanks for reporting this issue and please pipe up again if the backport doesn't show up in one of the next stable release (it can take 1-2 for things to trickle through).
(In reply to comment #17) > Ok, I've submitted the stable backport request for Thanks Daniel. I thought I'd closed this one already, but found the half filled comment box among a hundred open tabs with bug reports... :)
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.