Bug 18342

Summary: [GM965] White screen that fades to stripes with "intel" driver
Product: xorg Reporter: Robert Marmorstein <robert>
Component: Driver/intelAssignee: Jesse Barnes <jbarnes>
Status: RESOLVED DUPLICATE QA Contact: Xorg Project Team <xorg-team>
Severity: critical    
Priority: medium CC: brice.goglin, chrismenning, cub.uanic, drago, robert, suncoolsu
Version: 7.4 (2008.09)Keywords: NEEDINFO
Hardware: Other   
OS: All   
URL: https://bugs.edge.launchpad.net/xserver-xorg-video-intel/+bug/297245
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg Log File
none
Xorg.log with ModeDebug On
none
Output of lspci
none
VBIOS dump
none
rom.bin
none
dmesg.txt
none
another dmesg
none
fixup mode line for AUO display
none
Dell Studio 15 Video ROM File (1535 model: pp33L) sold by TELNOR, Mexico
none
Dell Studio 15 xorg log File (1535 model: pp33L) sold by TELNOR, Mexico
none
adjust h & vblank end none

Description Robert Marmorstein 2008-11-01 12:51:10 UTC
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.
Comment 1 Gordon Jin 2008-11-02 17:55:56 UTC
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.
Comment 2 Robert Marmorstein 2008-11-02 19:22:54 UTC
(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.


Comment 3 Robert Marmorstein 2008-11-02 19:26:22 UTC
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.
Comment 4 Robert Marmorstein 2008-11-02 19:28:54 UTC
Created attachment 20017 [details]
Xorg.log with ModeDebug On

This log file has "ModeDebug" option on.
Comment 5 Robert Marmorstein 2008-11-02 19:34:29 UTC
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
Comment 6 Robert Marmorstein 2008-11-02 19:37:51 UTC
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.
Comment 7 Gordon Jin 2008-11-02 21:40:04 UTC
Is this your first time to use intel driver on this machine? i.e. Is there an older version ever worked for you?
Comment 8 Robert Marmorstein 2008-11-04 00:48:42 UTC
(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!

Comment 9 Bryce Harrington 2008-11-19 08:43:53 UTC
Ubuntu bug 268036 is similar symptoms but different hardware so perhaps unrelated.  Ubuntu bug 297245 is a better match (same hardware).
Comment 10 Jesse Barnes 2008-11-19 13:55:45 UTC
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;
Comment 11 Chris Menning 2008-11-20 20:31:37 UTC
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
Comment 12 Robert Marmorstein 2008-11-20 21:21:29 UTC
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!
Comment 13 Bryce Harrington 2008-11-21 17:59:03 UTC
Created attachment 20501 [details]
rom.bin

Attached is Chris Menning's rom.bin
Comment 14 Jesse Barnes 2008-11-25 14:54:29 UTC
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.
Comment 15 Chris Menning 2008-11-26 18:02:57 UTC
Can I get some more specifics about what to do to get dmesg output? I'm very new at this type of thing.
Comment 16 Chris Menning 2008-11-27 00:52:26 UTC
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?
Comment 17 Mario Limonciello 2008-12-02 15:44:44 UTC
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.
Comment 18 Jesse Barnes 2008-12-09 08:49:05 UTC
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?
Comment 19 Sanvesh 2008-12-09 23:54:31 UTC
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?
> 

Comment 20 Sanvesh 2008-12-09 23:56:09 UTC
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?
> > 
> 

Comment 21 Bryce Harrington 2008-12-10 12:17:40 UTC
I've packaged a i386 .deb with Jesse's patch, which is available at
 http://people.ubuntu.com/~bryce/Testing/Intel-Bug297245/
Comment 22 Sanvesh 2008-12-10 14:29:27 UTC
(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

Comment 23 Boris Churzin 2008-12-11 01:21:07 UTC
(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?
Comment 24 Sanvesh 2008-12-15 04:07:03 UTC
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?
> 

Comment 25 Jesse Barnes 2008-12-17 16:19:03 UTC
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...
Comment 26 Alejandro 2008-12-22 14:20:04 UTC
Created attachment 21409 [details]
Dell Studio 15 Video ROM File (1535 model: pp33L) sold by TELNOR, Mexico
Comment 27 Alejandro 2008-12-22 14:21:33 UTC
Created attachment 21410 [details]
Dell Studio 15 xorg log File (1535 model: pp33L) sold by TELNOR, Mexico
Comment 28 Oleg Kostyuk 2009-01-04 16:01:37 UTC
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.
Comment 29 Jesse Barnes 2009-01-06 12:46:01 UTC
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.
Comment 30 Jesse Barnes 2009-01-12 16:57:30 UTC
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?
Comment 31 Boris Churzin 2009-01-13 07:10:23 UTC
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.
Comment 32 Jesse Barnes 2009-01-13 08:54:49 UTC
(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.
Comment 33 Jesse Barnes 2009-01-13 09:40:04 UTC

*** This bug has been marked as a duplicate of bug 17292 ***
Comment 34 Boris Churzin 2009-01-13 11:40:46 UTC
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.
Comment 35 Boris Churzin 2009-01-13 15:22:23 UTC
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?
Comment 36 Jesse Barnes 2009-01-13 15:43:16 UTC
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.
Comment 37 Oleg Kostyuk 2009-01-13 18:40:36 UTC
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!
Comment 38 Brice Goglin 2009-01-25 23:09:59 UTC
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.
Comment 39 Robert Marmorstein 2009-01-25 23:23:31 UTC
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....)  
Comment 40 Chris Menning 2009-01-26 06:32:04 UTC
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.
Comment 41 Jesse Barnes 2009-01-26 10:32:41 UTC
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.