Created attachment 100376 [details] dmesg ==System Environment== -------------------------- Regression: Yes. Non-working platforms: BDW-Y ==kernel== -------------------------- origin/drm-intel-nightly: 085391259463f3bda367fc3e078504d83cd8dc0e(works) drm-intel-nightly: 2014y-05m-29d-23h-55m-55s integration manifest origin/drm-intel-next-queued: 192155025197cc4765702a180904c3b62c152b7a(fails) drm/i915: Drop locking around fbdev-fb in debugfs origin/drm-intel-fixes: d23db88c3ab233daed18709e3a24d6c95344117f(works) drm/i915: Prevent negative relocation deltas from wrapping ==Bug detailed description== ----------------------------- Booting with eDP, monitor can't be lighted up after entering the kernel. I can't find a good commit on -next-queued ==Reproduce steps== ---------------------------- Boot with eDP ==Bisect results== ---------------------------- Bisect shows: 38aecea0ccbb909d635619cba22f1891e589b434 is the first bad commit: commit 38aecea0ccbb909d635619cba22f1891e589b434 Author: Daniel Vetter <daniel.vetter@ffwll.ch> AuthorDate: Mon Mar 3 11:18:10 2014 +0100 Commit: Daniel Vetter <daniel.vetter@ffwll.ch> CommitDate: Wed Mar 5 21:30:42 2014 +0100 drm/i915: reverse dp link param selection, prefer fast over wide again ... it's this time of the year again. Originally we've frobbed this to fix up some regressions, but maybe our DP code improved sufficiently now that we can dare to do again what the spec recommends. This reverts commit 2514bc510d0c3aadcc5204056bb440fa36845147 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Jun 21 15:13:50 2012 -0700 drm/i915: prefer wide & slow to fast & narrow in DP configs I'm pretty sure I'll regret this patch, but otoh I expect we won't make progress here without poking the devil occasionally. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73694 Cc: peter@colberg.org Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Itai BEN YAACOV <candeb@free.fr> Tested-by: David En <d.engraf@arcor.de> Reported-and-Tested-by: Marcus Bergner <marcusbergner@gmail.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At first, I didn't find a good commit. Because system always hang when I try to boot with earlier kernel. So I gave up finding a good commit. The next day, I tried again, and system hang didn't happen. So I did bisect.
CC Paulo, might be interesting to see if his patches to match recent BDW documentation updates make a difference here.
Paulo, do you have any ideas about this issue.
(In reply to comment #3) > Paulo, do you have any ideas about this issue. Please test drm-intel-nightly from today. The following commit is what we're interested in: drm/i915: update BDW DDI buffer translations http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly&id=9576c27f5287f873505583350049100896a48299
Actually, it also looks like your Kernel doesn't include the following commit: "drm/i915/dp: force eDP lane count to max available lanes on BDW" I believe it should fix the problem you reported.
(In reply to comment #0) > ==kernel== > -------------------------- > origin/drm-intel-nightly: 085391259463f3bda367fc3e078504d83cd8dc0e(works) > drm-intel-nightly: 2014y-05m-29d-23h-55m-55s integration manifest > origin/drm-intel-next-queued: 192155025197cc4765702a180904c3b62c152b7a(fails) > drm/i915: Drop locking around fbdev-fb in debugfs > origin/drm-intel-fixes: d23db88c3ab233daed18709e3a24d6c95344117f(works) > drm/i915: Prevent negative relocation deltas from wrapping > Now that I re-read this, it makes even more sense to me. It is normal and acceptable for certain things to work on drm-intel-nightly and drm-intel-fixes but fail on drm-intel-next-queued for a certain period of time. Sometimes patches are committed directly to -fixes, so -next-queued won't include the fix until it is merged back. I don't even consider cases like this as "bugs", and I certainly wouldn't classify such a case as P1/critical.
Failure on dinq but working on -nightly is not a bug. It simply means the bugfix hasn't been merged through dinq but some other tree. Usually -fixes to get the patch into the next -rc kernel.
(In reply to comment #7) > Failure on dinq but working on -nightly is not a bug. It simply means the > bugfix hasn't been merged through dinq but some other tree. Usually -fixes > to get the patch into the next -rc kernel. Agree with you. That makes sense. I retest and both -fixes and -nightly work well.
Closing verified+invalid.
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.