Created attachment 14049 [details]
Xorg.0.log of a running session

Created attachment 14050 [details]
xorg.conf

Created attachment 14051 [details]
lspci -vvn

Created attachment 14052 [details]
glxinfo -t -v

Please don't mind the video card Identifier in xorg.conf, I was just too lazy to rename it. The mentioned ATI card is not attached to the computer at the moment.

> If they are enabled, as per default,
> running glxgears gives a mostly black glxgears window, where gears are only
> occasionally seen when moving the window.
> 
I don't see this issue.  Are you sure glxgears run on the latest git/master version?  Why I can't find any information about "memory manager" in your Xorg.0.log ?

Yes, I'm fairly sure I'm running the latest:
- MESA: see glxinfo, it wouldn't say "2.0 Mesa 7.1" if it hadn't gotten into use the libGL* and i965_dri.so from the GIT version of MESA I built
- DRM/libdrm: latest git versions of both are being used, I checked that there are no multiple versions of those installed and the one that are in use are what I compiled from the latest GIT
- Xserver. As you can see from the Xserver log, it say 1.4.99.2, it's the GIT version from three days ago, compiled against the MESA GIT version and added with keyboard/mouse & intel DDX driver

So is there anything I'm missing? I'm also wondering what's causing the "Failed to initialize TTM buffer manager.", since in theory it should work/start with these? Is memory manager a separate module that should be compiled, or something that should be separately enabled with a configure option?

The idea is that cpp is no longer necessarily a global setting, you can have a GLXPixmap or a FBO with a different bit depth.  So we can't just look this up from the screen global setting.  Not sure why this assert triggers though, what's the actual value of region->cpp?

(In reply to comment #7)
> - DRM/libdrm: latest git versions of both are being used, I checked that there
> are no multiple versions of those installed and the one that are in use are
> what I compiled from the latest GIT

Do you use the latest DRM kernel module?

(In reply to comment #8)
> The idea is that cpp is no longer necessarily a global setting, you can have a
> GLXPixmap or a FBO with a different bit depth.  So we can't just look this up
> from the screen global setting.  Not sure why this assert triggers though,
> what's the actual value of region->cpp?
now the cpp of depth buffer is 3, but the actual value should be 4.

(In reply to comment #9)
> Do you use the latest DRM kernel module?

Yes, "DRM/libdrm" meant that I have both the kernel modules and libdrm compiled from GIT. dmesg says (the version numbers apparently aren't updated in any way when using modules from git):
[   31.278055] [drm] Initialized drm 1.1.0 20060810
[   31.428083] [drm] Initialized i915 1.12.0 20070209 on minor 0
[   31.428092] [drm] Used old pci detect: framebuffer loaded

The modules:
-rw-r--r-- 1 timo timo 5225698 2008-02-02 12:23 drm.ko
-rw-r--r-- 1 timo timo 1428061 2008-02-02 12:23 i915.ko

Regarding debugging, I get X hanged if I try to run the glxgears via gdb.

As an additional note, if I don't disable AIGLX & composite (ie. when glxgears semi-runs), and enable compiz, I get the whole screen completely garbled with colored noise. I can see eg. the shapes of windows, so I may blindly type metacity --replace in terminal to restore ungarbled view.

(In reply to comment #11)
> (In reply to comment #9)
> > Do you use the latest DRM kernel module?
> 
> Yes, "DRM/libdrm" meant that I have both the kernel modules and libdrm compiled
> from GIT. dmesg says (the version numbers apparently aren't updated in any way
> when using modules from git):
> [   31.278055] [drm] Initialized drm 1.1.0 20060810
> [   31.428083] [drm] Initialized i915 1.12.0 20070209 on minor 0
> [   31.428092] [drm] Used old pci detect: framebuffer loaded

I see the same issue if I use an old DRM kernel module (from 2.6.24-rc3), and the memory layout is same as your X.0.log.  So please double check your DRM (f.g Is your DRM from freedesktop.org, use insmod drm.ko/i915.ko before starting X, ) 

I insmodded the compiled drm & i915 modules from the GIT drm directory before starting X, the GIT drm is from git://anongit.freedesktop.org/git/mesa/drm and has eg. drm_ttc.c. I have the same problems regardless:
without composite/AIGLX, I get the error message mentioned. With composite/AIGLX (ie. Xorg default settings), either nothing is drawn in the 3D application's window or only eg. something like 256x256 tile of the 3D window is drawn. I get the "Failed to initialize TTM buffer manager." too in both cases.

It also seems I'm not the only one with these problems:
http://lists.freedesktop.org/archives/xorg/2008-January/031847.html (see the whole thread, he updates also to the master of mesa/drm in addition to mesa/mesa and intel ddx driver later on). He has probably not tried disabling AIGLX/composite, and is thus seeing only the "not shown completely/correctly" problem.

I eg. started Flight Gear and had only the upper left corner of the window drawn. Additionally, there were some graphical errors/noise (not as much when using full-screen compiz) even in the part that was drawn.

I can confirm the finding in that thread that reverting commit d9edd8e90588417e3d549f25132dab2f21445792 in mesa gets rid of the clipping problems and eg. glxgears is drawn when the window size is increased. Also Flight Gear works, but Compiz still shows only garbled screen when tried to be enabled.

This bug is getting bloated, feel free to advise on which issues should be separated to own bugs. The issues are:
1. TTM is not initialized
2. Only parts of 3D windows are shown
3. Even if 2. is fixed by reverting the specific git commit, Compiz window is garbled
4. If AIGLX/Composite is disabled, glxgears gives error message

Ah, after having a better search on the existing bugs, this bug can indeed be reduced to the original segmentation fault problem when AIGLX/Composite disabled + the compiz problem which might need its own bug still. The other two problems have their own bugs:

Adding dependency on bug #13922 as for the TTM not getting initialized problem. So at least that part can be handled there. It might be that the problem is caused by the lack of TTM.

Bug #14251 is handling the regression caused by the commmit d9edd8e90588417e3d549f25132dab2f21445792.

(In reply to comment #11)
> (In reply to comment #9)
> > Do you use the latest DRM kernel module?
> 
> Yes, "DRM/libdrm" meant that I have both the kernel modules and libdrm compiled
> from GIT. dmesg says (the version numbers apparently aren't updated in any way
> when using modules from git):
> [   31.278055] [drm] Initialized drm 1.1.0 20060810
> [   31.428083] [drm] Initialized i915 1.12.0 20070209 on minor 0
> [   31.428092] [drm] Used old pci detect: framebuffer loaded
framebuffer kernel module is used. Could you try without this module? see tips in 
http://intellinuxgraphics.org/how_to_report_bug.html

Created attachment 14143 [details] [review]
print more information about kernel memory manager

Could you apply with this patch to print more information about kernel memory manager, then post your new Xorg.0.log?

(In reply to comment #10)
> (In reply to comment #8)
> > The idea is that cpp is no longer necessarily a global setting, you can have a
> > GLXPixmap or a FBO with a different bit depth.  So we can't just look this up
> > from the screen global setting.  Not sure why this assert triggers though,
> > what's the actual value of region->cpp?
> now the cpp of depth buffer is 3, but the actual value should be 4.
> 
Hi, Kristian
 It seems the driver should use the cpp value gotten from Xserver for static buffers(front/back/depth), and this doesn't impact FBO or GLXpixmap, right?

Hi. Finally some progress, not on this bug as such but on the TTM issue. I wondered why your patch didn't output anything, and noticed the #ifdef DRI_MM in the code - turns out that I still had an old libdrm.pc pkgconfig file, which reported older version, which disabled DRI_MM in the intel DDX driver. So, as simple as that!

Anyway, this same error still occurs when AIGLX/Composite is disabled, but having the TTM is good anyway.

Created attachment 14150 [details]
new Xorg.0.log with TTM working

(In reply to comment #17)
> (In reply to comment #10)
> > (In reply to comment #8)
> > > The idea is that cpp is no longer necessarily a global setting, you can have a
> > > GLXPixmap or a FBO with a different bit depth.  So we can't just look this up
> > > from the screen global setting.  Not sure why this assert triggers though,
> > > what's the actual value of region->cpp?
> > now the cpp of depth buffer is 3, but the actual value should be 4.
> > 
> Hi, Kristian
>  It seems the driver should use the cpp value gotten from Xserver for static
> buffers(front/back/depth), and this doesn't impact FBO or GLXpixmap, right?

The problem is that AIGLX is disabled.  With the new GLX visual setup, the X server relies on AIGLX to load the driver and ask the DRI driver which visuals it supports.  This means that disabling AIGLX on the server will cause spurious visual mismatches as the server now uses the software renderers (GLcore) visuals but the direct rendering client tries to use the visuals returned by the DRI driver loaded on the client side.

However, we could probably do a better job of inferring the cpp fromt the visual; instead of assuming rgbBits / 8 is a suitable value, I guess we should do something like

  if (intel->ctx.Visual.rgbBits == 16)
    region->cpp = 2;
  else
    /* assume 32 bits per pixel */
    region->cpp = 4;

in intel_recreate_static().  But again the real problem comes from AIGLX being disabled, and the above fix will only paper over it.

Fix for the assertion failure is pushed.  Thanks!

Yep, verifying that commit c0e026c8090954ddb629a01cc1a93c61b2fc8298 fixes the issue for me.

Also, Kristian is correct that the fix only hides other problems regarding visuals when AIGLX is disabled, but at least something works also with it disabled now.

Mass version move, cvs -> git