hi! on newer kernels, whenever i modprobe i915 my screen goes black. the backlight is still on and the machine continues working but now as a headless system. by bisection i found the commit that introduced this regression: 885a5fb5b120a5c7e0b3baad7b0feb5a89f76c18 is the first bad commit commit 885a5fb5b120a5c7e0b3baad7b0feb5a89f76c18 Author: Zhenyu Wang <zhenyuw@linux.intel.com> Date: Tue Jan 12 05:38:31 2010 +0800 drm/i915: fix pixel color depth setting on eDP Original DP mode_valid check didn't take pixel color depth into account, which made one 1600x900 eDP panel's mode check invalid because of overclock, but actually this 6bpc panel does can work with x1 lane at 2.7G. This one trys to take bpp value properly both in mode validation and mode setting. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net> :040000 040000 3c99ae05b82db5b8e453d2062bcf56743794476b d7e0aa843fe4f8173f624572c77a7fe93b6fc455 M drivers this issue appears on my dell e6510 with intel hd (arrandale) and one can find many bugreports about the same effect on the e6410 and thinkpad x200s - all using said platform: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/554569 https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/561802 i also can confirm, that when removing the changes from this commit in the most recent intel_dp.c then my display even works on 2.6.34 :) as pointed out by zhenyu wang it might be related to bug#28070 cheers josch
Created attachment 35810 [details] intel_gpu_dump the normal gpu dump was too big so i gzipped it
Created attachment 35811 [details] dmesg
Created attachment 35812 [details] vbios
removed x201s from the title as that bug was solved by another fix and had only the same effect as this one
it seems to be unralated to bug#28070 since applying the patch from comment 21 in that bugreport did not change the reported behavior
Could you attach intel_reg_dump output in case of a) original failure; b) with my patch reverted to fix your issue?
Created attachment 35867 [details] intel_gpu_dump.gz 2.6.34 plain (non-working)
Created attachment 35868 [details] intel_gpu_dump.gz 2.6.34 patched (working)
Created attachment 35869 [details] [review] patch fixing the issue on 2.6.33-2.6.34 (revert of earlier commit)
i compiled 2.6.34 a) original failure - output found in comment#7 then i applied patch from comment#9 which partly reverts the changes of the breaking commit, rebuilt the kernel and obtained: b) your patch reverted - output found in comment#8 a) does not work, b) does work
josch, what I'd like to check is 'intel_reg_dumper' output, not 'intel_gpu_dump'.
Created attachment 35926 [details] intel_reg_dumper output non-working
Created attachment 35927 [details] intel_reg_dumper output working
whoops, sorry... turned out i had a very old version of the intel_gpu_tools which did not contain the intel_reg_dumper yet - got the git version and attached the output for a) with stock 2.6.34 in comment#12 (non-working) b) with patch reverted in comment#13 (working)
do you need any more info than the intel_reg_dumper outputs i attached a week ago? cheers
*** Bug 28481 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > Created an attachment (id=35869) [details] > patch fixing the issue on 2.6.33-2.6.34 (revert of earlier commit) This regression patch also worked for me, Vanilla Kernel 2.6.34 + Regression Patch + Fedora 13 on e6410 with A03 Bios. Thanks!
*** Bug 28539 has been marked as a duplicate of this bug. ***
Created attachment 36324 [details] [review] possible edp link clock overflow patch Could you try if this patch has any effect? Please use vanilla kernel without any reverts or workarounds. thanks.
to what kernel version is this patch supposed to apply - i can't find any that this patch matches to :(
Created attachment 36325 [details] [review] (resend) edp link clock overflow patch oops, mixed with another not commited patch. Please try this one against linus tree.
this patch didnt change anything here - even the intel_reg_dumper output is the same as posted above for the non-working case. the screen still goes black ones the module is loaded
I have the same problem on my E6410. I have unsuccessfully tried the following kernels on a 64 bit install of ubuntu 10.04: 2.6.32.21 (stock ubuntu 10.04 kernel) 2.6.32.22 (updated ubuntu 10.04 kernel) 2.6.34-rc3 (Unbuntu mainline builds: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.34-rc5-lucid/) 2.6.35-rc1 (Ubuntu mainline builds: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35-rc1-lucid) 2.6.34-drm-intel-next (Intel's DRM branch from ubuntu mainline builds: http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/2010-06-02-lucid ) All of these exhibited the same black screen failure. Finally, I've settled on Linus' vanilla mainline 2.6.35 kernel to test the patches attached to this bug. So far, none have worked. I get to the point of the boot where i915 goes into KMS mode, and the machine goes black if booting on the internal flat-panel. I am never able to ssh in, and the boot does not complete. If I switch the display at the BIOS to an external VGA display, it will boot to X.
http://lists.freedesktop.org/archives/intel-gfx/2010-June/007216.html please try this patch.
(In reply to comment #24) > http://lists.freedesktop.org/archives/intel-gfx/2010-June/007216.html > > please try this patch. Works for me :) thanks
yes, this fixes the issue i reported, thank you! although i read that this patch breaks other panels :/
http://lists.freedesktop.org/archives/intel-gfx/2010-June/007232.html new patch.
Hi , check bug #28224
(In reply to comment #28) > Hi , check bug #28224 Sorry forget this message I just want CC me . bug #28224, #28739, #28746 and #28070 seems very similar, and like "Paulo J. S. Silva", my problem is after resuming from suspend to RAM.
Could I mark this as duplicated of bug #28070 ? *** This bug has been marked as a duplicate of bug 28070 ***
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.