Comment 48 for bug 977804

Description of problem:
In Fedora 17, trying to run GNOME Shell on my second monitor (laptop's own screen disabled) works for a little while but then GNOME Shell suddenly disappears (windows are still there, but without a window manager). The following is printed to the terminal right before it disappears:
"intel_do_flush_locked failed: No space left on device"

My second monitor uses a resolution of:
1920x1080

The video card in my laptop is this:

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
 Subsystem: Hewlett-Packard Company Device 30b1
 Flags: bus master, fast devsel, latency 0, IRQ 16
 Memory at f4600000 (32-bit, non-prefetchable) [size=512K]
 I/O ports at 4000 [size=8]
 Memory at e0000000 (32-bit, prefetchable) [size=256M]
 Memory at f4680000 (32-bit, non-prefetchable) [size=256K]
 Expansion ROM at <unassigned> [disabled]
 Capabilities: <access denied>
 Kernel driver in use: i915

I believe the problem is due to the amount of memory available, 256MB, and GNOME Shell's use of 3D acceleration.

If I try using GNOME Shell with both my laptop's screen and the second monitor (not mirrored, so 1024 + 1920 wide), everything is unusably slow with mouse clicks taking 10 seconds or more to respond. If I try to use metacity + GNOME Panel, it works fine.

Version-Release number of selected component (if applicable):
gnome-shell-3.4.1-5.fc17

How reproducible:
Always

Steps to Reproduce:
1. enable second monitor (disabling laptop's own screen)
2. use GNOME Shell
3. open some windows (say 10) and work for a little while

Actual results:
GNOME Shell disappears

Expected results:
GNOME Shell persists. (Ideally, it could work with 1024+1920 wide screens too (so including first monitor.)

Additional info:
I tried running gnome-shell under gdb but it exits normally after printing that error message. I don't think anything is actually crashing. I didn't see anything particularly relevant in /var/log/Xorg.0.log, but I could look again if something should be there.