Created attachment 40251 [details] dmesg output and xorg logfile On my notebook (Lenovo IdeaPad U160 U3400), I get a black screen with the i915 kernel driver and KMS enabled. I am then able to start xorg via an ssh session but it doesn't help with the black screen. The problem exists with linux-2.6.36 and a git-clone of drm-intel (12th Nov. 2010).
Probably, this is a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=29647
Looks to be the same bug, but your dmesg is *so* much cleaner.
Interesting form factor. How easy is it to replace the HDD and ram? Pitty about the i3, but I guess that is just the thermal budget. Is it fanless?
(In reply to comment #2) > Looks to be the same bug, but your dmesg is *so* much cleaner. Thanks. Today I also tried Linus' tree (commit 9457b24a0955bbdd2e89220a75de69fe09501bba) and also Eric Aholt's drm-intel tree but that did not help. But, I learned how to get even more drm debug messages with drm.debug=0xff. If that is of interest, I will add a further attachment.
(In reply to comment #3) > Interesting form factor. How easy is it to replace the HDD and ram? Pitty about > the i3, but I guess that is just the thermal budget. Is it fanless? Well, I did not replace HDD and RAM so I can only guess that it would be a matter of removing about 8 screws. No, unfotunately it isn't fanless.
Today, I tested drm-intel-staging (commit 1bb95834bbcdc969e477a9284cf96c17a4c2616f) and still get a black screen.
(In reply to comment #6) > Today, I tested drm-intel-staging (commit > 1bb95834bbcdc969e477a9284cf96c17a4c2616f) and still get a black screen. What changed with this sources is that the backlight turns off when I load the i915 module. It turns on when I unload it: $ lsmod Module Size Used by snd_hda_codec_hdmi 20780 1 snd_hda_codec_realtek 301324 1 snd_hda_intel 21273 0 snd_hda_codec 63615 3 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel snd_pcm 69757 2 snd_hda_intel,snd_hda_codec snd_timer 18233 1 snd_pcm snd 55473 6 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_pcm,snd_timer i2c_i801 7008 0 atl1c 27059 0 snd_page_alloc 7133 2 snd_hda_intel,snd_pcm $ modprobe i915 # Backlight turns off $ lsmod Module Size Used by i915 355437 0 drm_kms_helper 26285 1 i915 drm 178240 2 i915,drm_kms_helper i2c_algo_bit 4603 1 i915 cfbcopyarea 3077 1 i915 cfbimgblt 2261 1 i915 cfbfillrect 3121 1 i915 snd_hda_codec_hdmi 20780 1 snd_hda_codec_realtek 301324 1 snd_hda_intel 21273 0 snd_hda_codec 63615 3 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel snd_pcm 69757 2 snd_hda_intel,snd_hda_codec snd_timer 18233 1 snd_pcm snd 55473 6 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_pcm,snd_timer i2c_i801 7008 0 atl1c 27059 0 snd_page_alloc 7133 2 snd_hda_intel,snd_pcm $ rmmod i915 drm_kms_helper drm i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect # Backlight turns on.
One more detail with a kernel 2.6.37-rc1-00518-g9457b24-dirty (Linus Torvald's repo with some DRM_DEBUG messages added by me): When I modprobe i915, then remove the loaded modules and then do a startx, I get coloured screens. When I first did this test, yesterday, it was turquoise, today, I got grey, turquoise and currently an orange screen.
I found the guide on how to report bugs and will attach outputs of - intel_gpu_dump (without and with xorg started) - vbios dump - xrandr --verbose The running kernel was built from drm-intel-staging, fbcon is statically built into the kernel. Confusing is that xorg says it uses a mode of 1366x768, while xrandr reports a current mode of 1920x1080.
Created attachment 40322 [details] vbios dump
Created attachment 40323 [details] Output of intel_gpu_dump (i915 module loaded, xorg not started)
Created attachment 40324 [details] Output of intel_gpu_dump (xorg started)
Created attachment 40325 [details] Output (incl. stderr) of xrandr --verbose
> Confusing is that xorg says it uses a mode of 1366x768, while xrandr reports a > current mode of 1920x1080. I realized that the mode of 1920x1080 was the one of the machine I am working on. I replace the attachment with the correct one.
Created attachment 40326 [details] Output (incl. stderr) of xrandr --verbose
*sigh* the guide needs updating. In this case the most critical information is actually reported by intel_reg_dumper and I would like to compare the register state before the i915.ko is loaded and afterwards (either console or X as they both fail to initialise the panel). However, the bug is likely to lie inside the FDI training which won't be so obvious from observing final register states.
(In reply to comment #16) > *sigh* the guide needs updating. In this case the most critical information is > actually reported by intel_reg_dumper When I check http://intellinuxgraphics.org/how_to_report_bug.html now, it only has intel_reg_dumper, no intel_gpu_dump.
(In reply to comment #17) > (In reply to comment #16) > > *sigh* the guide needs updating. In this case the most critical information is > > actually reported by intel_reg_dumper > > When I check http://intellinuxgraphics.org/how_to_report_bug.html now, it only > has intel_reg_dumper, no intel_gpu_dump. Sorry for that, I installed Version 1.0.2 of the gpu-tools and there was no intel_reg_dumper and I did not give it a deeper thought. Now, I cloned the latest sources and am having problems with building the tools: intel_batchbuffer.c: In function 'intel_batchbuffer_flush': intel_batchbuffer.c:111: error: 'I915_EXEC_BLT' undeclared (first use in this function) Using just a i915_drm.h from e.g. linux-2.6.37-rc3 introduces other problems. So, I need some more time to get the tools working...
Created attachment 40730 [details] intel_reg_dumper (drm-intel-staging 2.6.37-rc1-00551-g16c59ef)
In case that information is of interest: when I use the xorg vesa driver (agpgart and drm disabled in the kernel), I also have problems with blank screens when switching to a text console and when stopping or restarting xorg.
(In reply to comment #20) > In case that information is of interest: when I use the xorg vesa driver > (agpgart and drm disabled in the kernel), I also have problems with blank > screens when switching to a text console and when stopping or restarting xorg. Heh, that just means not even the BIOS can successfully light up the pipe 100% of the time. ;-)
Found one issue that could be related, and pushed a patch to drm-intel-staging: commit 109552bfeb04122b5c87126a56f87d1ecb3d058a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sat Dec 4 07:45:57 2010 +0000 drm/i915: Factor in pixel-repeat in FDI M/N calculation Fixes the modesetting on the secondary panel of the Libretto W100 and presumably many more Ironlake laptops with SDVO LVDS displays. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> commit 22ed1113a9adda6e193c329119a384362da01289 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sat Dec 4 01:01:29 2010 +0000 drm/i915: Death to the unnecessary 64bit divide Use the hardware DDA to calculate the ratio with as much accuracy as is possible. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org It's a bit of a long shot since there is nothing in your debug logs to suggest that it is the same problem. The lik
(In reply to comment #22) > Found one issue that could be related, and pushed a patch to drm-intel-staging: I tried that branch but the symptoms remain the same. Would it help if I attach Xorg.0.log or the output of intel_reg_dumper?
Created attachment 40798 [details] diff between previos intel_reg_dump and new one (2.6.37-rc4-00145-g2a944e4)
Out of obvious ideas, so down to poking the usual culprits. Try this to see if makes any difference whatsoever: diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d index d9b7092..d1543d7 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3792,7 +3792,7 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc, lane = bps / (link_bw * 8) + 1; } - intel_crtc->fdi_lanes = lane; + intel_crtc->fdi_lanes = lane = 4; if (pixel_multiplier > 1) link_bw *= pixel_multiplier;
(In reply to comment #25) > Out of obvious ideas, so down to poking the usual culprits. > > Try this to see if makes any difference whatsoever: > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_d > index d9b7092..d1543d7 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -3792,7 +3792,7 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc, > lane = bps / (link_bw * 8) + 1; > } > > - intel_crtc->fdi_lanes = lane; > + intel_crtc->fdi_lanes = lane = 4; > > if (pixel_multiplier > 1) > link_bw *= pixel_multiplier; No visual changes in symptoms, unfortunately. The diff of intel_reg_dumper output comes in a few moments.
Created attachment 40810 [details] Next diff against original intel_reg_dumper output.
I am thinking if it would be helpful and safe your time if you (Chris?) have physical access to this particular machine. I could imagine to give it away for some weeks if that makes sense.
I was looking at picking up a U160, but that always runs the risk of getting a working one ;-)
I went ahead and ordered one from Lenovo. Works like a charm.
(In reply to comment #30) > I went ahead and ordered one from Lenovo. Works like a charm. Interesting. Is it the same as mine (U3400 CPU, ModelName 0894 written on the bottom side)? Could you probably send me your kernel config, so that I cat test it here?
Created attachment 41064 [details] .config Model number is 0894. It has been known for Lenovo to use different parts in the same model before. I've attached my config, which a lightly customised debian config (I only did a very quick pass to avoid building a few categories of drivers).
ickle@u160:/usr/src/linux-2.6$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 37 model name : Intel(R) Core(TM) i3 CPU U 330 @ 1.20GHz stepping : 5 cpu MHz : 666.000 cache size : 3072 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm arat dts tpr_shadow vnmi flexpriority ept vpid bogomips : 2393.53 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
(In reply to comment #33) Tested a kernel built with your config but without success, unfortunately. My laptop has a different CPU > model name : Intel(R) Core(TM) i3 CPU U 330 @ 1.20GHz model name : Intel(R) Celeron(R) CPU U3400 @ 1.07GHz and a different graphics controller also, I would guess: 00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02)
GPU is a rev 02 Arrandale as well, so unlikely to be an unknown mysterious missing hardware workaround. I am *happy* to report that the panel remains obstinately blank (backlight on, but effectively disabled) after closing the lid. Something for me to attack, at least. With your black screen, is the backlight on or off?
(In reply to comment #35) > I am *happy* to report that the panel remains obstinately blank (backlight on, > but effectively disabled) after closing the lid. Something for me to attack, at > least. With your black screen, is the backlight on or off? The backlight is on. I guess, because the screen is not absolutely black but I can see some light at least at the bottom part of the screen. In an earlier comment I also wrote that this light can be turned off and on by loading and unloading modules.
I found it's much better behaved if I disable SSC: diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios index b0b1200..91934c1 100644 --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -262,7 +262,7 @@ parse_general_features(struct drm_i915_private *dev_priv, if (general) { dev_priv->int_tv_support = general->int_tv_support; dev_priv->int_crt_support = general->int_crt_support; - dev_priv->lvds_use_ssc = general->enable_ssc; + //dev_priv->lvds_use_ssc = general->enable_ssc; if (dev_priv->lvds_use_ssc) { if (IS_I85X(dev))
(In reply to comment #37) > I found it's much better behaved if I disable SSC: YEAH! My notebook behaves MUCH better: lena # xrandr Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192 LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 256mm x 144mm 1366x768 60.0*+ 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) I'm really happy. Thank you so much, Chris. Is there a rough explanation that you can give at least for partial understanding? What does SSC stand for?
At the moment, it's just an indicator of where the problem lies. SSC stands for Spread-Spectrum Control and is a mode in which the display reference clock is allowed to vary slightly (power efficiency is the normal reason). Either the panel is lying in its ability to handle SSC or we are misprogramming one of the umpteen sequence points required to set up the SSC reference clock. Dirk, thanks for confirming that we're on the right track. Enjoy your laptop, hopefully I'll have a refined patch to test in a short while.
Created attachment 41123 [details] [review] Fix selection of 100 vs 120Mhz SSC clock Without actual documentation for the contents of the VBT, this is at least empirically correct.
Undid the previous modification and applied that patch and can confirm: works like a charm ;-) Tested restarts of xorg as well as switches to text consoles, closing and opening the lid; everything works well.
Dirk, thank you for all the testing. I've applied the patch to drm-intel-fixes where it will be (shortly) merged into Linus' kernel and from there into the stable backports and the distros.
*** Bug 29647 has been marked as a duplicate of this bug. ***
Thank you for working on this issue, Chris. An early but definitely very nice christmas present at least to me ;-)
I confirm that Chris' patch fixes the problem on my U160 laptop. Thank you so much Chris!
Unfortunately, this commit cause a black screen on my Toshiba Satellite L670? It seems other people have encountered the same problem (see the answers to Linus's post 2.6.37-rc8 on LKML). Until kernel 2.6.37-rc7, everything was working fine.
(In reply to comment #46) > Unfortunately, this commit cause a black screen on my Toshiba Satellite L670? > It seems other people have encountered the same problem (see the answers to > Linus's post 2.6.37-rc8 on LKML). Until kernel 2.6.37-rc7, everything was > working fine. We're using bug#32698 to track the side effect of this patch.
I had the exact same symptoms on my U160, so I was very happy to read about the fix. Unfortunately it does not seem to work on my model, I have a 1.33 GHz core i3 U380 cpu (or as cpuinfo puts it: model name: Intel(R) Core(TM) i3 CPU U 380 @ 1.33GHz). Not even disabling SCC completely seems to do anything, which I guess either makes it a different issue or a screw up on my end when testing the fix. Have anyone else tested this fix on my kind of CPU?
Tobias: my U160 is a Core i3-380UM too, and the 1-line patch works beautifully. I manually applied it to a vanilla kernel (2.6.36 IIRC).
And a heads up: I had to revert the patch for 2.6.37, so we will need to keep manually applying it until I can find one that doesn't cause regressions elsewhere, bug 32748. If anybody has the opportunity to test whether modesetting works well under the Windows driver, I'd be grateful. Even more so if you can somehow contrive to get a register dump.
My mistake. The patch works, but the screen goes black when X starts.
Hello all, I'm currently running Win 7 on my U160 and I'm willing to do required tests on Windows or Linux OS. My knowledge is not on the same level as yours are so I hope you don't mind to paste some extra line that I will be able to do required tests. Best regards, Peter
Today, I tested linux-2.6.38-gentoo and the display is working fine as long as I don't close the lid. After reopening it, the display remains dark. I noticed that this bug has been marked fixed what seems to be correct, but according to the comments I cannot realize how it has been done.
I am using archlinux with kernel 2.6.38 and can confirm the problem, that the display goes blank on closing the lid and stays blank after reopening it.
(In reply to comment #51) > My mistake. The patch works, but the screen goes black when X starts. Same problem here. I applied the patch on fedora's 2.6.35.13-91.fc14.x86_64 and recompiled it. Well I had to make my own parch since the code was a little different, but the patch was successfuly applied. Ans the screen still goes blank when X start. I get a 'no screen found' error when trying startx in command line. Would the end of my Xorg.0.log help? And can we reopen the bug?
My bad, I had a nomodeset remaining in the wrong place. It works wonderfully now. Tobias, you might also want to check that if the screen still goes blank. Thanks to everyone who tried hard on this, and let's hope a compromise will soon be found so that it works on all the configs.
(In reply to comment #53) > Today, I tested linux-2.6.38-gentoo and the display is working fine as long as > I don't close the lid. After reopening it, the display remains dark. Between 2.6.38 and 2.6.39 a commit reintroduced the blank screen problem during boot on my machine. Using the kernel parameter 'i915.lvds_use_ssc=0' solves both, my blank screen and reopen lid problems. Many thanks to Jesse Barnes. [1] https://lkml.org/lkml/2011/5/31/387
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.