Created attachment 91929 [details] dmesg output Tested on Dell Venue 11 Pro tablet (Haswell i5 4210Y, Intel HD4200). Tested this with the following distros, all with various versions of Xorg and Linux Kernel. Ubuntu 14.04 (daily iso build, up to latest) Ubuntu 13.04 Ubuntu 12.04.3 Fedora 20 daily build Debian Wheezy Arch Linux daily build With "nomodeset", I get varying levels of success when booting from legacy mode. when booting with UEFI, I've had no such luck. The only common error I've found across many of the distros is the following error: [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting [drm:intel_dp_start_link_train], too many full retries, give up
Created attachment 91941 [details] kern.log file my kern.log output too (Ubuntu 14.04 daily build)
PSR panel. 337500KHz CDCLK. 18bpp + dither. PCI ID ending in 0xE. All the unusual stuff together...
Is this a no hope case or just a difficult one to solve? Is there anything that I can do in the meantime to further identify the bug?
Please grab latest intel-gpu-tools and attach the output of intel_reg_dumper for both the working and the broken case.
Have you tried kernel version v3.13-rc1 or later?
(In reply to comment #2) > All the unusual stuff together... Paulo seems to know about this...
Created attachment 93199 [details] register dump booted with nomodeset
Created attachment 93200 [details] register dump without nomodeset (black screen)
I ran into the same problem on 3.13.1. Also tested drm-intel-fixes, but still not fixed there. For more information, I created register dumps booting with and without "nomodeset" kernel parameter.
Reg dumper says "Dumping from file without -d argument. Assuming Ironlake machine.". Something seems wrong. How did you run intel-reg-dumper? Please just do "sudo ./intel_reg_dumper > file" and we should be fine.
Created attachment 93527 [details] new regdump without nomodeset kernel parameter (black screen)
Created attachment 93528 [details] new regdump with nomodeset kernel parameter
I had an old version of intel_gpu_tools and dumped the registers to file before running the reg_dumper. Generated both new dumps directly with version 1.5.
Created attachment 94727 [details] output of intel_reg_dumper this is the attachment of the requested output from running "sudo intel_reg_dumper > log"
Looking at the dumps, I found, that there are only 2 lanes activated. Increasing the intel_dp->lane_count to max_lane_count during the initialization in intel_dp_compute_config resolves this issue and link training succeeds.
Please try drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel.
This problem was still not fixed in the nightly branch 4 days ago, when i found this workaround. I will try again within the next few days and post the results.
update on the current state of the nightly branch: kernel hangs at boot since commit 294ae7b44bba7ab0d4cef9a8736287f38bdb4fd without any BUG/OOPS/WARN and also without output from drm.debug=0xe link training still failed until the commit before that: b2040f6fed736ccd2319768bc59833abe74148b8
Created attachment 95839 [details] Workaround: Unconditionally activate all lanes on eDP port This is the quick hack i made to activate "max_lane_count" lanes for link training to succeed.
Aside: Same issue seems to happen on bdw, too. Looking at the provided register dumps the bios indeed goes with a 4x lane config. I guess we finally need to implement that bit of spec language that says if link training fails we need to retry with lowered clocks.
Markus, please attach /sys/kernel/debug/dri/0/i915_opregion. If it's not too much trouble, please check if it's different for legacy boot vs. UEFI, and if there's a difference, please attach both. Thanks.
Please try the two patches attached to bug 76711 and report back. (https://bugs.freedesktop.org/show_bug.cgi?id=76711#c14)
Created attachment 97772 [details] contents of /sys/kernel/debug/dri/0/i915_opregion booted with uefi
Created attachment 97773 [details] contents of /sys/kernel/debug/dri/0/i915_opregion booted with legacy bios
with both your patches applied to 3.14.0, link train succeeds perfectly on my machine.
(In reply to comment #25) > with both your patches applied to 3.14.0, link train succeeds perfectly on > my machine. Daniel, take note: 3.14 did not even prefer fast over wide yet.
(In reply to comment #25) > with both your patches applied to 3.14.0, link train succeeds perfectly on > my machine. Wait. The patches do not apply cleanly on 3.14. Does unpatched vanilla v3.15-rc2 work for you?
I merged the patch into the kernel by hand "patch -p1 -l --merge < ..." I will post the results for 3.15-rc2 this evening
v3.15-rc2 unpatched does not work v3.15-rc2 patched works fine
Markus, please try http://patchwork.freedesktop.org/patch/24813/ (and only that patch) on otherwise unpatched 3.14 and 3.15-rc2. Thanks.
the max_lane_count has already the correct value (4), so the last mentioned patch has no effect here. but tested anyway on v3.15-rc2 without success.
commit 0aa7de323a32ca0b27769901b9607fc892b90dbc Author: Jani Nikula <jani.nikula@intel.com> Date: Tue May 6 14:56:52 2014 +0300 drm/i915: use lane count and link rate from VBT as minimums for eDP pushed to drm-intel-fixes (and updated to drm-intel-nightly) branch of http://cgit.freedesktop.org/drm-intel. Markus, as this will be queued for 3.15, I would very much appreciate it if you could verify that either of the branches now work for you. Thanks.
I just tested drm-intel-fixes and it works fine. Thank you very much for your patches!
(In reply to comment #33) > I just tested drm-intel-fixes and it works fine. Thank you very much for > your patches! No, thank you very much for testing! ;)
Closing resolved+fixed. Verified by second reporter.
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.