Screen gets blank (backlight enabled) after loading i915 module with modeset enabled. X starts but screen still blank. Only workaround is to boot with kms disabled (i915.modeset=0) and VESA driver for Xs. The problem exists even if X is not started, just loading i915 with modeset is enough to get blank screen. System environment: -- chipset: GM45 [8086:2a42] -- system architecture: 64-bit -- xf86-video-intel: 2:2.9.1-3ubuntu5 -- xserver: 1:7.5+5ubuntu1 -- mesa: -- libdrm: 2.4.18-1ubuntu3 -- kernel: 2.6.32 / 2.6.36 -- Linux distribution: Ubuntu 10.04 -- Machine or mobo model: Vostro V13 Core2duo -- Display connector: LVDS1 Reproducing steps: Booting without i915.nomodeset=1 kernel parameter is enough to get blank screen. Additional info: Tried Ubuntu 10.04 with kernel 2.6.32, also tried ubuntu 10.10, and vanilla 2.6.36 on ubuntu 10.04, none works. I tried pipeA quirk using the following patch but it didn't worked (confirmed that quirk was applied on boot): diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 9792285..4cc1d93 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -5921,6 +5921,8 @@ struct intel_quirk { }; struct intel_quirk intel_quirks[] = { + /* Dell Vostro v13 needs pipe A force quirk (LP: #NNNNNN) */ + { 0x2a42, 0x1028, 0x042b, quirk_pipea_force }, /* HP Compaq 2730p needs pipe A force quirk (LP: #291555) */ { 0x2a42, 0x103c, 0x30eb, quirk_pipea_force }, /* HP Mini needs pipe A force quirk (LP: #322104) */ lspci, dmidecode, intel_reg_dumper, xorg and xrandr output attached for broken kms enabled boot, and for working nomodeset+vesa boot.
Created attachment 40099 [details] broken intel_reg_dumper output
Created attachment 40100 [details] Broken Xorg.0.log
Created attachment 40101 [details] broken dmesg.log
Created attachment 40102 [details] broken xrandr.log
Created attachment 40103 [details] dmidecode.txt
Created attachment 40104 [details] lspci-vvnn.txt
Created attachment 40105 [details] vbios.dump
Created attachment 40106 [details] working dmesg.log
Created attachment 40107 [details] working intel_reg_dumper
Created attachment 40108 [details] working Xorg.0.log
Created attachment 40109 [details] working xrandr.log
Any thoughts on this? I own this hardware, know how to compile new kernels, apply patches, debugging, C and git. Just give me a hint on what to look for.
The most likely cause is that we've programmed the wrong clocks for the LVDS for the mode. Different modes will have different clocks and it's quite likely that a lower resolution will work. Try creating an xorg.conf to select a different mode, even easier if you can log in remotely and change modes using xrandr. Then is is just a matter of working out in what way and why they are broken. Could be that we don't respect some limit correctly, or we are choosing the wrong refclck, or number of channels, etc.
Any chance of testing a recent kernel such as drm-intel-next?
(In reply to comment #14) > Any chance of testing a recent kernel such as drm-intel-next? Since my last report I tested with: - Ubuntu 10.10 2.6.35 (comes with distro) - Ubuntu 10.10 2.6.36 (from kernel.org) - Ubuntu 10.10 2.6.37 (from kernel.org) Only with 2.6.37 and only two times I was able to get correct resolution but screen started to show squares after moving mouse. I have no idea what triggered the correct resolution as I didn't changed anything except removing the nomodeset kernel parameter. I tried to ssh into the box running with KMS enabled (and blank screen of course) but xrandr doesn't list modes to switch (I have not the output here), basically it lists two modes with zeros in frequency column. Anyway, my laptop is in DELL warranty service since Monday, it had broken the motherboard (ETA 2 weeks)
Any update?
The 2 weeks were obviously longer than expected, but the great news are that video was fixed after service replaced something they called "audioboard". Thanks! and apologies for not updating this ticket before.
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.