Bug 23718

Created attachment 29230 [details]
BootDmesg.txt

Created attachment 29231 [details]
CurrentDmesg.txt

Created attachment 29232 [details]
XorgLog.txt

Created attachment 29233 [details]
XorgLogOld.txt

Created attachment 29234 [details]
xranr.txt

Created attachment 29235 [details]
xorg.log

Created attachment 29236 [details]
task_i915_0_834_blocked.txt

Could you try if recent kernel, rc9 has bug, pls try recent git?

just tried with the 2.6.31 ubuntu kernel in karmic, no change.

Could you boot kernel with drm.debug=15 and attach dmesg in failure?

Created attachment 29507 [details]
grep drm in syslog with drm.debug=15

Created attachment 29550 [details] [review]
[debug] disable watermark update

Could you try with this debug patch against kernel 2.6.31? It's possible watermark relate issue.

Created attachment 29576 [details]
log with patch, still hangs

tried again with patch, still freezes,
only change is that the mouse can be moved for one second,
also to the laptop screen, freezes after that.

attached syslog after logging in:
 attaching external monitor
 opening gnome-display-properties
 moving mouse
 freeze

How about try with xrandr utility instead of gnome-display-property? Does "xrandr --auto" work for you after you plug in VGA?

with xrandr --auto, both screens go black, did not see a mouse pointer.

I've tried to reproduce this with ubuntu karmic alpha5. The problem is with composite, when I removed compiz gnome behaves right. It will try to set extended desktop when external VGA plugged in, if compiz is on with metacity, the screen just went blank, if no compiz, gnome displays right.

But the clone mode can work right in compiz. So not sure if this is another front buffer rendering issue?

disabling effects and just running metacity,
external monitor seams to work fine. (with and without your patch)
with compiz it does not work though

(In reply to comment #16)
> But the clone mode can work right in compiz. So not sure if this is another
> front buffer rendering issue?

is this a bug in compiz or the intel driver?
with another laptop with intel chip i did not see those issues running compiz.

anything that can be done to further debug this?
would be nice to get this fixed for the next ubuntu release.

what's the chip type of that another laptop?

Ian, can you take a look? Zhenyu think it's not 2d driver issue.

Summary so far:
1. Compiz fusion is required to reproduce this. Unfortunately it's enabled by
default in Karmic. Disabling Compiz fusion or even using Compiz core (like
default in Fedora 11) doesn't have this problem.
2. This happens on 945, but fine on 965.
3. This happens for extended desktop, but fine for clone mode.

(In reply to comment #19)
> what's the chip type of that another laptop?
> 
that one that works is a GM965:

00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
	Subsystem: Apple Computer Inc. Device 00a1
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 28
	Region 0: Memory at 90100000 (64-bit, non-prefetchable) [size=1M]
	Region 2: Memory at 80000000 (64-bit, prefetchable) [size=256M]
	Region 4: I/O ports at 6110 [size=8]
	Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
		Address: fee0300c  Data: 4199
	Capabilities: [d0] Power Management version 3
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
		Bridge: PM- B3+
	Kernel driver in use: i915
	Kernel modules: i915

00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
	Subsystem: Apple Computer Inc. Device 00a1
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Region 0: Memory at 90200000 (64-bit, non-prefetchable) [size=1M]
	Capabilities: [d0] Power Management version 3
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
		Bridge: PM- B3+

Sorry for anonymous login (ubuntu/launchpad 451126 submitter). Anyhow interesting to note that this works even in compiz as long as you don't exceed what will fit in hardware at once.

http://www.intel.com/design/mobile/datashts/309219.htm
1.3.2.1 LVDS Interface
         • Dual-channels LVDS interface support: 2 x 18 bpp panel support up to  QXGA (2048 x 1536)
1.8.5 LVDS Interface
       • 25 MHz –112 MHz single channel; @18 bpp
       • Panel support up to XGA (1024 x 768) internal and SXGA (1280 x 1024) external

If my combined resolution is below 2048x1536 it will work fine while having compiz effects in both screens.
If you start with this resolution, you won't crash anything by increasing
resolution, you'll just get blank screen and you can wait it out to get
previous mode or press ESC to get it immediately.

I am seeing the same issue, with ubuntu karmic on a lenovo S12.

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

i can confirm that it is triggered by wide opengl. if i disable compiz then i can use xrandr --auto to enable the external VGA screen. then if i run glx gears, it runs ok. if i resize the glxgear wider across both screens i get the crash again.

let me know if there is any extra info i can provide.

*** Bug 23835 has been marked as a duplicate of this bug. ***

Any update? This issue appears critical and also impacts Moblin, so I'm considering this as true Q4 release blocker.

It seems unlikely that this will be fixed anytime soon.  It's a hardware limitation that prevents 3D rendering to a drawable wider than 2048.  I don't have a good sense for how we could work around that.

*** Bug 24746 has been marked as a duplicate of this bug. ***

even if it is hard to make rendering wider than 2048 work. maybe it is is possible to make attempts to render wider than 2048 fail more gracefully, rather than crashing X.

I think rendering at e.g. 2048x1024 should work ok though; we must have a bug in the 3D driver that prevents that from working somehow.

Haihao, can you take a look?

Falling back more gracefully would be nice too; we definitely shouldn't crash the X server, but I'm not sure there's much we can do about the compositing manager drawing garbage.

Bug 24746 which has been marked a duplicate of this, might be a little different in terms of a solution.

The problem I noticed was that xv didn't work on displays larger than 2048 (with no compositing window manager).  I'm guessing that the textured video interface suffers the same limitations here as the compositing window managers.  A while ago there was also a video overlay - could that be exposed again and would it work on large displays?

It would be nice to be able to watch video on one screen or the other, eg for presentations.

It looks like some Ubuntu developer fixed this bug in compiz, see the comment in the original bug report:
---
(https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/419328/comments/74)
Fixed package is available at https://launchpad.net/~compiz/+archive/ppa/+sourcepub/890268/+listing-archive-extra (tested and approved)

@Yingying: the packages mentioned in the Launchpad comment do *not* fix the problem for me, neither the ones in the compiz PPA nor those in karmic-proposed. Launchpad is currently in read-only maintenance mode, so I haven't been able to mention this there yet.

Hey there, I believe this problem is not compiz-specific, it also happens to me with Mutter. See: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/414240

I also see something similar with kwin (KDE 4.3.4): when I turn on the output to a external monitor with total resolution 2034x1024, kwin immediately disabled compositing. If go to the kwin settings it says that compositing is suspended, and when I try to "resume" it, it doesn't work. (So far so good).

BUT, if I try to re-start kwin by running kwin --replace I get a black screen, so I think this might be the same problem.

Should I report this as a kwin bug instead of a driver bug?

(In reply to comment #34)
> I also see something similar with kwin (KDE 4.3.4): when I turn on the output
> to a external monitor with total resolution 2034x1024, kwin immediately
> disabled compositing. 

I think automatically disabling compositing is the best workaround for this bug at this point (much better than blank screen), so kwin does the best.

Can Ubuntu do the same for Compiz fusion before this bug is completely fixed (which needs huge effort and probably won't happen in 3 months)?

its not just compositing window managers that would need to work around this. i can trigger it with plain metacity by enlarging a glxgears window across 2 screens.

could xorg (or mesa or whatever) refuse to draw beyond the max safe width, either giving a rendering glitch, or passing the error to the client to deal with. even if the client crashed, its better than X crashing.

isn't there goal that no client can crash X, similar to how a application should not be able to crash the kernel

I just pushed a patch to mesa_7_6_branch and mesa_7_7_branch that should mostly fix this issue.  The problem is that 915 and related chipsets cannot handle a pitch of >4096 bytes, so we have to fallback to software for now.  This patch seems to work fine in gears on mesa_7_6_branch, but the rendering is incorrect on mesa_7_7_branch.  I believe this is a separate issue.

Could folks test with this patch?

commit f23d01e726a57cd6b8e31f1049ee5853773df7ea
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Tue Dec 15 12:14:04 2009 -0800

    intel: Fallback to software if drawable size is > MaxRenderbufferSize
    
    This prevents the mystery blank window if, for example, glxgears is
    resized larger than 2048 wide on 915.  Since the Intel drivers in Mesa
    7.6 lack GTT mapped fallbacks, the performance is a slideshow at
    best.  On Mesa 7.7 and later the performance is much better.

Created attachment 32096 [details]
Image showing corruption on mesa_7_7_branch with width >2048

Tested against Mesa 7.6 on Ubuntu Karmic 9.10 on Samsung NC10 netbook, with compiz enabled.
Internal monitor resolution is 1024x600, external one is 1280x1024.

Now, attaching the external monitor and running xrandr, both screens turn and remain black, however X server does not freeze anymore and I can move the mouse pointer across the (black) screens.

Anyway, the X server remains in an not usable state, and all I can do is to restart it.
After the restart with the external monitor unplugged, everything works again but it's VERY slow.

If you need further testing, feel free to ask.

If any Ubuntu Karmic user wants to test the patch by himself, Mesa packages with the patch already applied are available on my PPA repository (i386 and lpia architectures only):

https://launchpad.net/~voria/+archive/archive

Tested against Mesa 7.7 on 945GME with the patch (commit f23d01e726a57cd6b8e31f1049ee5853773df7ea), OS is fedora 11. 

If compiz disabled, it works fine for extended desktop, laptop and external srceen display right. Gears also works well with 2048 width. 

If compiz enabled, after attaching external monitor and setting extended desktop, the gnome rendering actions becomes very slow. About display, for laptop screen, it displays right, for the external monitor, part of the screen displays right, the other part is blank.

By the way, if use commit 11522b74b318db9d099466ff226124c23595e8e2, X crashs when setting extended desktop. The commit info is following:
commit 11522b74b318db9d099466ff226124c23595e8e2
Merge: b90f7f3 f23d01e
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Tue Dec 15 12:38:01 2009 -0800

    Merge branch 'mesa_7_6_branch' into mesa_7_7_branch

    Conflicts:
        src/gallium/drivers/softpipe/sp_quad_blend.c

This patch works on both mesa7.7 but not working on mesa7.6, still got blank screen if width >= 2048

This patch works on mesa7.7 but not working on mesa7.6, still got blank screen if width >= 2048

(In reply to comment #43)
> This patch works on mesa7.7 but not working on mesa7.6, still got blank screen
> if width >= 2048

The Intel drivers in Mesa 7.6 use a different method to access memory for software fallbacks.  As a result, software fallbacks on 7.6 are, literally, 100 times slower than on 7.7.  If it works on 7.7, I'd bet that you just didn't wait long enough on 7.6.  "Long enough" might be several minutes for a single frame.  This isn't something we can fix in 7.6, unfortunately.

After updating the 2D driver on my test system, I'm no longer able to reproduce the tiling errors that I reported earlier (see attachment #32069 [details]).  As a result, I'm going to close this bug as fixed.

(In reply to comment #44)
> After updating the 2D driver on my test system, I'm no longer able to reproduce
> the tiling errors that I reported earlier (see attachment #32069 [details]).  

That should be attachment #32096 [details].