When launching X, a white screen comes up that slowly fades to an uneven pattern of colored lines. The display is unusable. Display works fine with "vesa" driver. Also, connecting an external CRT works with the "intel" driver. The problem seems to only happen with this LVDS (I have a Dell Studio 15 Laptop). X.org logfile shows these error messages: (EE) intel(0): I830 Dma Initialization Failed Could not init font path element /usr/share/fonts/TTF, removing from list! (EE) intel(0): underrun on pipe B! [config/dbus] couldn't take over org.x.config: org.freedesktop.DBus.Error.AccessDenied (Connection ":1.126" is not allowed to own the service "org.x.config.display2" due to security policies in the configuration file) expected keysym, got XF86Info: line 914 of inet expected keysym, got XF86Info: line 914 of inet expected keysym, got XF86Info: line 914 of inet expected keysym, got XF86Info: line 914 of inet expected keysym, got XF86Info: line 914 of inet (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! ^Cerror setting MTRR (base = 0xe0000000, size = 0x10000000, type = 1) Invalid argument (22) Others have seemingly run into this issue. There is a bug posted on an Ubuntu forum (I use ArchLinux) here: https://bugs.launchpad.net/bugs/268036 which may have more information. Thanks for any help.
When you file bugs, please provide more info (at least the full Xorg.0.log) according to http://intellinuxgraphics.org/how_to_report_bug.html. If your chipset is GM45, this bug seems similar to bug#17292 or 17508.
(In reply to comment #1) Thanks for responding so quickly! > When you file bugs, please provide more info (at least the full Xorg.0.log) > according to http://intellinuxgraphics.org/how_to_report_bug.html. Sorry about that. I will attach more information. > > If your chipset is GM45, this bug seems similar to bug#17292 or 17508. > These are certainly similar, but the graphical artifacts are different. In 17292, the screen is just blank. In 17508, there is a single red line on the left. The behavior I am seeing is an all white screen that slowly fades to a pattern of colored vertical lines. So I think there is a good chance this is a separate issue.
Created attachment 20016 [details] Xorg Log File I've played around with Xorg.conf a lot with no luck. This is one of the Log files I generated.
Created attachment 20017 [details] Xorg.log with ModeDebug On This log file has "ModeDebug" option on.
More information about my setup: chipset: X3100(GM965) system architecture: x86_64 xf86-video-intel/xserver/mesa/drm version: git 20081023-1 (I have also tried with 2.5.0-1) kernel version: 2.6.27-ARCH Linux distribution: Archlinux Machine or mobo model: Dell Studio 15 (1535) Display connector: LVDS
Created attachment 20018 [details] Output of lspci Here is the output of lspci on that machine. Please let me know if there is any other information I can provide.
Is this your first time to use intel driver on this machine? i.e. Is there an older version ever worked for you?
(In reply to comment #7) > Is this your first time to use intel driver on this machine? i.e. Is there an > older version ever worked for you? > Yes, this is a brand new Dell Studio Laptop that came with Linux pre-installed. I have never had a working version of the intel driver on this machine. I have tried to use git bisect to try some old versions out, but have not yet been able to find a version that works with this screen. Dell replaced the LVDS and the motherboard on this system, but the problem persists. I will continue to go back through the git log trying older versions of the driver. If I can help in any other way, please let me know!
Ubuntu bug 268036 is similar symptoms but different hardware so perhaps unrelated. Ubuntu bug 297245 is a better match (same hardware).
I don't have one of these platforms to test with. I noticed that the driver is trying to enable spread spectrum clocking though. I don't know what type of corruption you'd see if the platform didn't support it, but it could definitely cause problems. This patch disables SSC usage and might help. Can someone with one of the affected machines attach their vbios to this bug? # cd /sys/devices/pci0000\:00/0000\:00\:02.0/ # echo 1 > rom # cat rom > /tmp/rom.bin # echo 0 > rom Thanks. diff --git a/src/i830_display.c b/src/i830_display.c index 006b634..bee3185 100644 --- a/src/i830_display.c +++ b/src/i830_display.c @@ -1251,7 +1251,7 @@ i830_crtc_mode_set(xf86CrtcPtr crtc, DisplayModePtr mode, xf86DrvMsg(pScrn->scrnIndex, X_INFO, "clone detected, disabling SSC\n"); /* Don't use SSC when cloned */ - if (is_lvds && pI830->lvds_use_ssc && num_outputs < 2) { + if (is_lvds && pI830->lvds_use_ssc && num_outputs < 2 && 0) { refclk = pI830->lvds_ssc_freq * 1000; xf86DrvMsg(pScrn->scrnIndex, X_INFO, "using SSC reference clock of %d MHz\n", refclk / 1000); @@ -1331,7 +1331,7 @@ i830_crtc_mode_set(xf86CrtcPtr crtc, DisplayModePtr mode, /* dpll |= PLL_REF_INPUT_TVCLKINBC; */ dpll |= 3; } - else if (is_lvds && pI830->lvds_use_ssc && num_outputs < 2) + else if (is_lvds && pI830->lvds_use_ssc && num_outputs < 2 && 0) dpll |= PLLB_REF_INPUT_SPREADSPECTRUMIN; else dpll |= PLL_REF_INPUT_DREFCLK;
I have the exact same Dell Studio 1535 with the same problem. This command doesn't work cd /sys/devices/pci0000\:00/0000\:00\:02.0/ I don't have that directory in my system. I'm going to assume that you meant # cd /sys/devices/pci0000:00/0000:00:02.0 Now I enter all this... # cd /sys/devices/pci0000:00/0000:00:02.0 echo 1 > rom # cat rom > /tmp/rom.bin # echo 0 > rom and I don't really get any feedback. So to view the file I type this... # sudo nano /tmp/rom.bin at the contents of the rom.bin file don't look like tells much of anything usuable. It's mostly jumbled but contains this 00IBM VGA Compatible BIOS. @$VBT CRESTLINE and then this... ^C1533Intel(r)Crestline PCI Accelerated SVGA BIOS Build Number: 1318 PC 14.18 04/06/2006 18:05:12 DECOMPILATION OR DISASSEMBLY PROHIBITED ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@Copyright (C) 2000-2003 Intel Corp. All Rig$ And then after more garbled mess there's Total time for VGA initialization < 10 MilliSeconds
Created attachment 20485 [details] VBIOS dump Here is a dump of my VBIOS on a system that has the bug. I am returning the system to Dell tomorrow so I won't be able to access it any more, but I did try applying the spread-spectrum patch you posted. I applied it to xf86-video-intel version 2.4.2 recompiled it and gave it a try. I still get the white screen with the funny bars. Thanks for trying, though!
Created attachment 20501 [details] rom.bin Attached is Chris Menning's rom.bin
Hm, your DMA init call is failing, can you attach your kernel dmesg as well? That DRI failure path isn't well tested so could be part of the problem. Your video bios seems to have a reasonable mode, and your panel looks like it has an EDID, so the mode timings should be ok.
Can I get some more specifics about what to do to get dmesg output? I'm very new at this type of thing.
Created attachment 20622 [details] dmesg.txt I did this while using the command dmesg > dmesg.txt while using the vesa driver. Is it necessary that I use the intel driver, kill x, and then create the file?
Created attachment 20751 [details] another dmesg Here's another dmesg from another Studio 1535 that reproduces this problem only when that LCD model/vendor is used. Switching to another model/vendor combination and the problem goes away.
Created attachment 20957 [details] [review] fixup mode line for AUO display Here's a hack to make the HTotal on this display a bit more sensible. I wasn't able to reproduce the type of corruption you saw on my machine even with some weird mode lines, but different panels are sensitive to timing in different ways... Can someone give it a try?
Jesse or Mario, I would be honored to test this fix on my Studio 1535 (AUO LCD) -I don't know where to put this piece of Code? -How or where to execute this code? -Mario would u have enough time to put a step by step how to? In the meanwhile: I added the following modeline in my xorg.conf file and with this i can increase my display to 1024x768 (but not 1280x800 as suggested by the modeline) modeline "1280x800@60" 83.46 1280 1344 1480 1680 800 801 804 828 -hsync +vsync Thanks (In reply to comment #18) > Created an attachment (id=20957) [details] > fixup mode line for AUO display > > Here's a hack to make the HTotal on this display a bit more sensible. I wasn't > able to reproduce the type of corruption you saw on my machine even with some > weird mode lines, but different panels are sensitive to timing in different > ways... Can someone give it a try? >
A quick addition: this modeline worked only under "vesa" driver. If i changed my driver to "intel". I again got the WSoD. Thanks (In reply to comment #19) > Jesse or Mario, > I would be honored to test this fix on my Studio 1535 (AUO LCD) > > -I don't know where to put this piece of Code? > -How or where to execute this code? > -Mario would u have enough time to put a step by step how to? > > In the meanwhile: I added the following modeline in my xorg.conf file and with > this i can increase my display to 1024x768 (but not 1280x800 as suggested by > the modeline) > > modeline "1280x800@60" 83.46 1280 1344 1480 1680 800 801 804 828 -hsync +vsync > > Thanks > > (In reply to comment #18) > > Created an attachment (id=20957) [details] [details] > > fixup mode line for AUO display > > > > Here's a hack to make the HTotal on this display a bit more sensible. I wasn't > > able to reproduce the type of corruption you saw on my machine even with some > > weird mode lines, but different panels are sensitive to timing in different > > ways... Can someone give it a try? > > >
I've packaged a i386 .deb with Jesse's patch, which is available at http://people.ubuntu.com/~bryce/Testing/Intel-Bug297245/
(In reply to comment #21) > I've packaged a i386 .deb with Jesse's patch, which is available at > http://people.ubuntu.com/~bryce/Testing/Intel-Bug297245/ > Hi Bryce, I have a 64 bit machine (heron for amd64) - can u do the same thing for my architecture? I will be thankful. Regards
(In reply to comment #21) > I've packaged a i386 .deb with Jesse's patch, which is available at > http://people.ubuntu.com/~bryce/Testing/Intel-Bug297245/ > Hi, installed the deb file, didn't help, do I need to do something else for this ? rebuild or something?
Hi All, Just to update you all guys..I dont know if it will be helful I got 1280x800 resolution on my ubuntu (Hardy Heron-amd64) using Vesa Driver. In order to get this i did 2 things mainly: 1) Added this modeline - modeline "1280x800@60" 83.46 1280 1344 1480 1680 800 801 804 828 -hsync +vsync (some of the people said it will give me 1280x800 resolution with Vesa - but for me it didnt work out that way) saving this to the xorg.conf file and killing X gave me 1024x768 resolution. 2) After this - i used the 915 resolution patch. Killing X after this patch I was able to boot in 1280x800. This is only with vesa driver. If I use INTEL instead of VESA I still get the WSoD. Thx (In reply to comment #23) > (In reply to comment #21) > > I've packaged a i386 .deb with Jesse's patch, which is available at > > http://people.ubuntu.com/~bryce/Testing/Intel-Bug297245/ > > > > Hi, > installed the deb file, didn't help, do I need to do something else for this ? > rebuild or something? >
Interesting... Hopefully I'll be getting the hw soon; sounds like that modeline works ok this hw, so either xf86-video-intel is still programming the wrong mode or there's something else going wrong with our panel programming...
Created attachment 21409 [details] Dell Studio 15 Video ROM File (1535 model: pp33L) sold by TELNOR, Mexico
Created attachment 21410 [details] Dell Studio 15 xorg log File (1535 model: pp33L) sold by TELNOR, Mexico
Hello, I have same hardware (Studio 1535 with AUO LCD) and same problem. Do we have some progress? At this moment I'm using Debian Lenny 64bit with latest versions of software from experimental repository. Yesterday I tried Kubuntu 8.10 in live mode, and see that on VGA-connected monitor all works just fine, even KDE4 3d and composite features. But on LVDS I see same as described in comment#2 - white screen that slowly fade to vertical lines. I can do some tests if you need it - hope that it's help us to get this bug resolved faster. Also I can make photos of picture on LVDS or even give you ssh access. Feel free to contact me personally via email. Thanks.
This one may be related to 17292 in that we're not starting up panels correctly in our driver. I've got a query open with the hw folks about it.
Created attachment 21911 [details] [review] adjust h & vblank end I could have sworn we had someone test something like this, but it works on the machine I just received. Can someone confirm it works for them too?
I'm not sure I did everything right, but it didn't work for me. What I did: git checkout xf86-video-intel-2.5.1 changed the stuff in i830_bios.c ./autogen.sh make sudo make install rmmod i915 rmmod drm insmod /lib/modules/2.6.27.7-9-default/kernel/drivers/gpu/drm/drm.ko insmod /lib/modules/2.6.27.7-9-default/kernel/drivers/gpu/drm/i915/i915.ko xinit -- :1 -verbose Please tell me if I did something wrong.
(In reply to comment #31) > I'm not sure I did everything right, but it didn't work for me. > What I did: > > git checkout xf86-video-intel-2.5.1 I was actually testing against xf86-video-intel-2.4.3, but that shouldn't matter. > changed the stuff in i830_bios.c > ./autogen.sh > make > sudo make install ^^^ This step may have put your intel_drv.so in the wrong place, which would prevent X from picking it up when you start it via xinit. On my machine, intel_drv.so is in /usr/lib/xorg/modules/drivers; you can backup the version there and overwrite it with src/.libs/intel_drv.so from your custom build for testing. > rmmod i915 > rmmod drm > insmod /lib/modules/2.6.27.7-9-default/kernel/drivers/gpu/drm/drm.ko > insmod /lib/modules/2.6.27.7-9-default/kernel/drivers/gpu/drm/i915/i915.ko > xinit -- :1 -verbose > > Please tell me if I did something wrong. Looks good other than what I noted above. Thanks for testing.
*** This bug has been marked as a duplicate of bug 17292 ***
I LOVE YOU !!! deeply! it works, at last... I think that it did catch before, but not sure, I compiled with 2.4.3 and copied the .so, compiz is wobbly like never before :) Thanks you very very much.
Works with 2.5.0 too. I've got some problems with compiz, and 3d I think. It crashes sometimes, and sometimes hangs the system (may be only keyboard). No compiz mode works perfect (though it hanged when launched xmoto). Don't know if it's related to this bug. May be I need to recompile mesa or something?
For compiz you'll almost certainly want to use the Q4 release (you can find the RC tarballs at intellinuxgraphics.org) since we fixed a lot of bugs that affect compiz recently.
Works for me too, thanks for your effort! Writing now from notebook with new driver ;) I'm just created debian-amd64 packages (builded on lenny, partially experimental), and resuls available here: http://ftp.cub.org.ua/debian/, Just for into: I'm using config-less Xorg, and currently have: cub@humsterbook ~ % xrandr Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280 VGA disconnected (normal left inverted right x axis y axis) LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 331mm x 207mm 1280x800 56.0*+ 800x600 56.2 TMDS-1 disconnected (normal left inverted right x axis y axis) cub@humsterbook ~ % xrandr Compiz and 3d effects is not tested by me. glxgears works without problems and give me 55.8 fps - both with default window size and with maximized. Thanks again for great job!
What's going on with this bug? Patch in comment#30 seems to help many people, but maybe not the original reporter? Is the patch going to be applied soon? (to both master and 2.6 branch please :)) Or are we talking about multiple/different bugs here? Thanks.
As the original reporter, I will add that the patch works for me, too. In fact, I am posting this from the problem hardware. (I decided to keep the laptop after all, when I saw how hard you guys were working on this thing -- especially after I saw that Dell did the right thing and sent hardware out. If only their technical support guys were more conversant with Linux and spoke better English....)
I agree with Robert. I also had this problem with my Dell, and they eventually did the right thing by sending out hardware. Ever since I got my working Dell Studio laptop in the mail, I've really been enjoying it. The new laptop uses a different LCD panel that didn't have the same issues related to the bug, and I've been able to upgrade to 8.10 with very little hassle.
Yeah sorry the patch hasn't been integrated upstream; will do this week so it'll show up in 2.6.2 and 2.7.
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.