Description: After updating to latest kernel release my screen goes black every time I boot laptop. Just after first few lines of kernel init logs. Then screen goes black, I can control LCD brightness but I don't see anything. Even if I switch to console I don't see anything. I'm able to start computer "somehow normal" by adding "i915.modeset=0" to kernel init parameters via GRUB. Then I see CMD in low resolution. Now I downgraded to Linux v3.4.8 and everything works fine with lates Intel driver. Additional info (I use Arch Linux distribution): * xf86-video-intel 2.20.7-1 * Linux 3.5.3-1 (not working) * Linux 3.4.8 (working) * X log: http://pastebin.com/AK5bshMr * dmesg output: http://pastebin.com/fgjKyRxV Steps to reproduce: Get laptop such as mine (Dell Lattitude E5510) update it to latest version of packages and reboot.
Two things: - please boot with drm.debug=0xe on the broken kernel and then attach complete dmesg (you might need to stitch it together from logfiles if you can't log in remotely). - can you please bisect where this regression has been introduced? Since this seems to affect only this special machine I fear we need the exact commit that introduced the regression to fix this. Last but not least, it seems your system has edp (and very likely cpu edp given it's a laptop, I need the debug dmesg to decide). We've recently merged some fixes for cpu edp support on ilk for 3.7, can you please try the drm-intel-next-queued branch at http://cgit.freedesktop.org/~danvet/drm-intel
I cannot provide any information now, because I use this laptop for production. With the beginning of next month I'll receive a backup PC, so I'll be able to experiment a bit with laptop.
Dropping priority until we can actually start with debugging ...
I performed test you asked. Instead using Linux 3.5 I used Linux 3.6, but without luck - I still have black screen. I attached dmesg output with enabled DRM debugging (see dmesg_3_6). I also tested kernel from drm-intel-next-queued and unfortunately problem is still present. I also attach dmesg output with enabled DRM debugging for this kernel too (see dmesg_drm-intel-next-queued).
Created attachment 82131 [details] dmesg_3_6
Created attachment 82141 [details] dmesg_drm-intel-next-queued
Bumping priority, because requested information was provided.
Sorry for the confusion, I've pointed you at the wrong branch. The edp fix is actually in the drm-intel-fixes branch, specifically commit: commit 0c96c65b48fba3ffe9822a554cbc0cd610765cd5 Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Sep 26 18:43:10 2012 +0300 drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag
(In reply to comment #8) > Sorry for the confusion, I've pointed you at the wrong branch. The edp fix is > actually in the drm-intel-fixes branch, specifically commit: > > commit 0c96c65b48fba3ffe9822a554cbc0cd610765cd5 > Author: Jani Nikula <jani.nikula@intel.com> > Date: Wed Sep 26 18:43:10 2012 +0300 > > drm/i915: use adjusted_mode instead of mode for checking the 6bpc force > flag This line in the dmesg: [ 0.686614] [drm:intel_dp_mode_fixup], DP link bw 0a lane count 1 clock 270000 bpp 18 indirectly says force 6 bpc is requested, and [ 1.783508] [drm:intel_choose_pipe_bpp_dither], setting pipe bpc to 8 (max display bpc 8) reveals 8 bpc is used anyway. The commit referred to by Daniel in drm-intel-fixes should cover this.
Confirm, everything is working fine with drm-intel-fixes branch for me. Do these fixes will land in mainline kernel branch for 3.7 release?
Patch is already on track to get merged into Linus' git tree, from which it should then get backported to all supported stable branches in a few days. Thanks for reporting this issue, I'll close it as fixed. commit 0c96c65b48fba3ffe9822a554cbc0cd610765cd5 Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Sep 26 18:43:10 2012 +0300 drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag