Thanks for the bug report.  We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Created attachment 291454 [details]
xorg.conf as requested

Default except for "virtual" line to allow xrandr to have enough memory to use
multihead

Created attachment 291455 [details]
xorg log with xorg.conf

This is the xorg log when started with the xorg.conf attached

Created attachment 291456 [details]
xorg log without xorg.conf

This is the xorg log without any xorg.conf - the behavior does not change.

Also note that this was NOT fixed with xorg-x11-drv-i810-2.2.0-3.fc9 and
xorg-x11-server-Xorg-1.4.99.1-0.15.20080107.fc9

I'm getting a similar problem with i386 arch.

Xorg also crashes when trying to start glxgears

I can actually run glxgears without a problem on x86_64 (but not compiz)

Compiz started working for me again (Thinkpad X60, i810) with
kernel-2.6.24.1-28.fc9.i686.

It still won't work for me (X61s, intel, x86_64, same kernel). 

Simon, did you try i810?

i810 has no support for my chipset (GMA X3100)

Sorry, silly mistake.

This works for me as of.. sometime in the past week. Simon, any luck trying
compiz in current rawhide?

I just updated, same problem. Note that this is x86_64 and not i686. 

Please let me know if you need any more information.

Latest behavior, rawhide current as of today, is that hardware GLX rendering is
not enabled. (I did try with and without an xorg.conf, and with both kernels
kernel-2.6.24.1-31.fc9.x86_64 and kernel-2.6.25-0.93.rc4.fc9.x86_64)

Nb: this looks like possibly a dupe of 435969.

Running Xorg under gdb:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ff0ef829780 (LWP 7942)]
0x0000003b26a84f2b in memcpy () from /lib64/libc.so.6
(gdb) bt full
#0  0x0000003b26a84f2b in memcpy () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007ff0df1a39e1 in dri_fake_reloc_and_validate_buffer
(bo=0x7ff0d4de5ab0)
    at /usr/include/bits/string3.h:52
        i = 0
        ret = <value optimized out>
        __PRETTY_FUNCTION__ = "dri_fake_reloc_and_validate_buffer"
#2  0x00007ff0df1a38c8 in dri_fake_reloc_and_validate_buffer
(bo=0x7ff0d1aef9c0)
    at ../common/dri_bufmgr_fake.c:1006
        r = (struct fake_buffer_reloc *) 0x7ff0d0f35350
        i = 0
        ret = <value optimized out>
        __PRETTY_FUNCTION__ = "dri_fake_reloc_and_validate_buffer"
#3  0x00007ff0df1a38c8 in dri_fake_reloc_and_validate_buffer
(bo=0x7ff0d1af0400)
    at ../common/dri_bufmgr_fake.c:1006
        r = (struct fake_buffer_reloc *) 0x7ff0d0f75390
        i = 1
        ret = <value optimized out>
        __PRETTY_FUNCTION__ = "dri_fake_reloc_and_validate_buffer"
#4  0x00007ff0df1a38c8 in dri_fake_reloc_and_validate_buffer
(bo=0x7ff0d337cd70)
    at ../common/dri_bufmgr_fake.c:1006
        r = (struct fake_buffer_reloc *) 0x7ff0d1738300
        i = 161
        ret = <value optimized out>
        __PRETTY_FUNCTION__ = "dri_fake_reloc_and_validate_buffer"
#5  0x00007ff0df1a3bb4 in dri_fake_process_relocs (batch_buf=0x7ff0d337cd70, 
    count_p=0x7ffff7854e44) at ../common/dri_bufmgr_fake.c:1045
        ret = <value optimized out>
        __PRETTY_FUNCTION__ = "dri_fake_process_relocs"
#6  0x00007ff0df1a4387 in _intel_batchbuffer_flush (batch=0x1e3acc0,
file=<value optimized out>, 
    line=<value optimized out>) at intel_batchbuffer.c:134
        intel = (struct intel_context *) 0x1af2830
        used = 3600
        was_locked = 0 '\0'
#7  0x00007ff0df1b8fb7 in intelTexImage (ctx=0x1af2830, dims=2, target=3553,
level=0, 
    internalFormat=6408, width=48, height=48, depth=1, border=0, format=32993,
type=5121, 
    pixels=0x7ff0d871e34c, unpack=0x1afed20, texObj=0x7ff0d354bdf0,
texImage=0x7ff0d354d590, 
    imageSize=0, compressed=0) at intel_tex_image.c:319
        intel = <value optimized out>
        intelImage = <value optimized out>
        postConvWidth = 48
        postConvHeight = 48
        texelBytes = <value optimized out>
        sizeInBytes = <value optimized out>
        dstRowStride = <value optimized out>
        srcRowStride = 48
        __FUNCTION__ = "intelTexImage"
        __PRETTY_FUNCTION__ = "intelTexImage"
#8  0x00007ff0df1b9f4d in intelTexImage2D (ctx=0x7ff0db1c2700, target=9216,
level=1152, 
    internalFormat=-128, width=0, height=<value optimized out>, border=0,
format=32993, type=5121, 
    pixels=0x7ff0d871e34c, unpack=0x1afed20, texObj=0x7ff0d354bdf0,
texImage=0x7ff0d354d590)
    at intel_tex_image.c:564
No locals.
#9  0x00007ff0df2484a6 in _mesa_TexImage2D (target=3553, level=0,
internalFormat=6408, width=48, 
    height=48, border=0, format=32993, type=5121, pixels=0x7ff0d871e34c) at
main/teximage.c:2564
        texObj = (struct gl_texture_object *) 0x7ff0d354bdf0
        texImage = (struct gl_texture_image *) 0x7ff0d354d590
        face = 0
        postConvWidth = 48
---Type <return> to continue, or q <return> to quit---
        postConvHeight = 48
        ctx = (GLcontext *) 0x7ff0db1c2700
#10 0x0000000000e24cd3 in __glXDisp_TexImage2D (pc=0x7ff0d871e318 "") at
indirect_dispatch.c:1153
No locals.
#11 0x0000000000e0ac0d in __glXDisp_RenderLarge (cl=0x1b26dd8,
pc=0x7ff0d01122a0 "")
    at glxcmds.c:1979
        client = (ClientPtr) 0x1b26c80
        dataBytes = 9216
        glxc = (__GLXcontext *) 0x1adf480
        error = <value optimized out>
        opcode = 110
        sw = <value optimized out>
#12 0x0000000000e0e9e2 in __glXDispatch (client=0x1b26c80) at glxext.c:492
        stuff = (xGLXSingleReq *) 0x7ff0d0112290
        opcode = <value optimized out>
        cl = (__GLXclientState *) 0x1b26dd8
        retval = 1
#13 0x00000000004462d4 in Dispatch () at dispatch.c:454
        clientReady = <value optimized out>
        result = <value optimized out>
        client = (ClientPtr) 0x1b26c80
        nready = 0
        start_tick = 46220
#14 0x000000000042c7bd in main (argc=8, argv=0x7ffff78552b8, envp=<value
optimized out>)
    at main.c:441
        i = 1
        error = 0
        xauthfile = <value optimized out>
        alwaysCheckForInput = {0, 1}

We recently fixed some things with glx and crashing, can everybody involved
please retest with rawhide from 2008 04-05 or later?

With Rawhide 20080405, the behavior is different - GLX (3d/AIGLX/DRI) is not enabled at all. This is true 
with or without an xorg.conf. 

Please let me know what info you need. Thinkpad X61s, Rawhide upgraded from F8 (would it be beneficial 
to do a clean install from a snapshot?), Intel X3100, x86_64. 

 

Just as a small update - rawhide updated last night, while compiz and glxinfo
still aren't happy I can get etracer (extreme tuxracer) to notice that there is
3d support.

However, a couple of screens in (I can select a course but can't get as far as
testing it), I get a complete graphics lockup. The only way to shutdown is to
hit the (thankfully ACPI controlled, so soft shutdown) power button. 

No crash/debug reports that I can find (i.e. no trace in xorg.0.log), but I can
try to get a better trace on things if somebody can point me to a howto or
similar. (and I did turn framebuffer compression off before getting this far, as
per some of the other bugs on this or related issues)

Latest rawhide, as of today, I do have something that claims to be DRI. I can
run a couple of the demos (i.e. glxgears), but only at about the same speed as
unaccelerated 3D (i.e. 350fps in glxgears on an X3100). 

However, after I run a couple of the demos, Xorg crashes. Compiz also still
doesn't work - white screen (control-c will get you back though if run as compiz
--replace in a terminal) with the following errors:
[skarpen@localhost ~]$ compiz --replace
Failed to initialize TTM buffer manager.  Falling back to classic.
failed to create drawable
failed to create drawable
failed to create drawable

The crash has the following backtrace (I will attach the full Xorg log):

0: X(xf86SigHandler+0x65) [0x479f55]
1: /lib64/libc.so.6 [0x3b2a2322a0]
2: /usr/lib64/xorg/modules/extensions//libdri.so(DRIUnlock+0x4f) [0x7faf968456af]
3: /usr/lib64/xorg/modules/drivers//intel_master_drv.so(I830WaitLpRing+0x18a)
[0x7faf95fc22fa]
4: /usr/lib64/xorg/modules/drivers//intel_master_drv.so(I830Sync+0x115)
[0x7faf95fc2565]
5: /usr/lib64/xorg/modules//libxaa.so [0x7faf948987c2]
6: X(AbortDDX+0x8d) [0x460a3d]
7: X(AbortServer+0x18) [0x4f5f78]
8: X(FatalError+0xd5) [0x4f6645]
9: /usr/lib64/xorg/modules/drivers//intel_master_drv.so(I830WaitLpRing+0x1c1)
[0x7faf95fc2331]
10: /usr/lib64/xorg/modules/drivers//intel_master_drv.so(I830Sync+0x115)
[0x7faf95fc2565]
11: /usr/lib64/xorg/modules//libxaa.so [0x7faf948a17db]
12: /usr/lib64/xorg/modules//libxaa.so [0x7faf948eb210]
13: X [0x530240]
14: X(miPaintWindow+0x1f6) [0x4cb086]
15: X(miWindowExposures+0x132) [0x4cb3e2]
16: /usr/lib64/xorg/modules/extensions//libdri.so(DRIWindowExposures+0xaf)
[0x7faf96845fcf]
17: X [0x48f13f]
18: X(miHandleValidateExposures+0x2b) [0x4e389b]
19: X(miMoveWindow+0x277) [0x4e2b67]
20: X(compMoveWindow+0xb5) [0x4fcd75]
21: X(ConfigureWindow+0x5ac) [0x432bdc]
22: X(ProcConfigureWindow+0x8d) [0x445a0d]
23: X(Dispatch+0x364) [0x446394]
24: X(main+0x45d) [0x42c87d]
25: /lib64/libc.so.6(__libc_start_main+0xfa) [0x3b2a21e32a]
26: X(FontFileCompleteXLFD+0x279) [0x42bc59]

Again, this is x86_64. 

Created attachment 302831 [details]
new xorg log with crash

Can you try the mesa packages available at:
http://koji.fedoraproject.org/packages/mesa/7.1/0.28.fc9/ ?

Definitely better. I can now run the glx demos (glxgears, geartrain, fire, etc)
for a while without an X server crash. Still can't run compiz though - "compiz
--replace" still gives me the same drawtable errors and white screen (but clean
recovery once I kill it off). 

etracer (extreme tuxracer) gives me a DRI error that I'll try to capture (again,
better than the old behavior of crashing the X server)

Oh, and performance is WAY down - less than 150fps in glxgears, engine is down
to around 60fps from 80fps. This on an X3100...

Looks like etracer is getting an assertion failure in the DRI code somewhere...

Extreme TuxRacer SVN Development --  http://www.extremetuxracer.com 
(c) 2007 The ETRacer team
(c) 2004-2005 The PPRacer team
(c) 1999-2001 Jasmin F. Patry<jfpatry>
ETRacer comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to redistribute it under certain conditions.
See http://www.gnu.org/copyleft/gpl.html for details.

Failed to initialize TTM buffer manager.  Falling back to classic.
%%% etracer warning: Attempt to bind to Texture unloaded texture:
`b-herring_run_icon'

etracer: ../common/dri_bufmgr_fake.c:982: dri_fake_emit_reloc: Assertion
`target_fake->is_static || target_fake->size_accounted' failed.

Just to be clear, when this is happening, what versions of kernel,
xorg-x11-server-Xorg, and driver do you have (to go with the newer mesa)

Performance is absolutely miserable for me with this combo:

xorg-x11-server-Xorg-1.4.99.901-22.20080415.fc9.x86_64
mesa-libGL-7.1-0.28.fc9.x86_64
kernel-2.6.25-1.fc9.x86_64

(Seems the bug I opened about that this morning is a dupe of what this has
evolved into -- bug #443080)

versions here are 

xorg-x11-server-Xorg-1.4.99.901-22.20080415.fc9.x86_64
xorg-x11-drv-i810-2.2.1-20.fc9.x86_64
kernel-2.6.25-0.234.rc9.git1.fc9.x86_64

(as in, latest rawhide as of last night)

(In reply to comment #25)
> Definitely better. I can now run the glx demos (glxgears, geartrain, fire, etc)
> for a while without an X server crash. Still can't run compiz though - "compiz
> --replace" still gives me the same drawtable errors and white screen (but clean
> recovery once I kill it off). 

try running 

LIBGL_ALWAYS_INDIRECT=1 compiz --replace --indirect-rendering 

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

LIBGL_ALWAYS_INDIRECT=1 compiz --replace --indirect-rendering 

is different but still not quite working - I at least get my screen back, but
compiz doesn't start. (control-c'ing does quit, and restarting metacity isn't a
problem)

Failed to initialize TTM buffer manager.  Falling back to classic.

I see this as well on Macbook 2,1 (blackbook) with Intel GMA950.  Compiz will work, sometimes, for a 
short period, then the screen will go completely WHITE.  The mouse cursor can still be moved, and 
commands can still be typed into terminals that were running and focused.  Killing compiz or using 
metacity --replace works fine, X is not frozen.

When I install compiz-fusion, or try using the external compiz repo it never manages to work at all.  
With only compiz installed I can sometimes work with the menus for awhile before the white happens.

Using indirect rendering does nothing useful to help, and glxinfo reports direct rendering is enabled 
anyway.  Some 3D games work with metacity running so the hardware is working somewhat.

Created attachment 303605 [details]
output of compiz with white screen, lspci -v, and Xorg.0.log after starting compiz several times

Created attachment 304010 [details]
Xorg.0.log

Comment on attachment 304010 [details]
Xorg.0.log

This seems to be the same problem, different platform

# uname -a
Linux apogee8.apogeect.com 2.6.24.3-50.fc8 #1 SMP Thu Mar 20 14:47:10 EDT 2008
i686 athlon i386 GNU/Linux

Occurs when running Firefox and nothing else

If it's not causing Xorg to segfault immediately anymore, then this bug should
be closed. The white-screen problem is a separate issue.

Is compiz still making Xorg segfault or not?

No more segfault here, just miserable rendering performance (even after the
libpciaccess update a few days ago).

Yeah you're right its a separate issue, but is the white screen and TTM buffer issue reported in another 
bug yet or does a clone need done?  I don't see that issue specifically in another bug  but maybe I'm 
missing it.

No more segfault here either, just the miserable rendering performance and the
white screen. 

Please report the white screen + render issues as another bug/cloned bug. Thanks!