mesa-dri broken on breezy

(In reply to comment #0)
> This bug is intended for the *breezy* release (I couldn't find a proper bugzilla
> for breezy, so I'm filing this here).

This Bugzilla is for Ubuntu main. Breezy is the current development release of
Ubuntu, so bug reports for packages in Breezy main go here.

that's because you're using xlibmesa-dri, not libgl1-mesa-dri. this is yet
another very good reason to keep ubuntu-desktop installed.

I assumed the name of the package was still xlibmesa-dri. You are right, I have
ubuntu-desktop and this bug applies to libgl1-mesa-dri, so it should be
considered still unresolved (I still have the problem).

cheers

and you've restarted X since upgrading to xserver-xorg* 6.8.2-57 or so? try
doing so now, if you haven't done so recently.

I have just installed xorg-* version 6.8.2-61, and restarted X (I reboot my PC
every night anyway). I get the same error message. I'll try to compile and
install mesa-cvs to see if the problem is still there.

cheers

I confirm the error about the sizeof(RADEONDRIRec) goes away, but DRI is still
not available (even if Xorg.0.log shows it is enabled). Maybe this is because
now libGL is out of sync with libdri.a (so xorg-core).

cheers

the output of LIBGL_VERBOSE=debug glxinfo might be useful in working out why DRI
is not available

(In reply to comment #7)
> the output of LIBGL_VERBOSE=debug glxinfo might be useful in working out why DRI
> is not available

These are the first lines of LIBGL_VERBOSE=debug glxinfo command:

name of display: :0.0
display: :0 screen: 0
direct rendering: No
server glx vendor string: Brian Paul
server glx version string: 1.4 Mesa 6.5
server glx extensions:
    GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap,
    GLX_MESA_release_buffers, GLX_ARB_get_proc_address, GLX_EXT_visual_info,
    GLX_EXT_visual_rating, GLX_SGI_video_sync, GLX_SGIX_fbconfig,
    GLX_SGIX_pbuffer

As you can see I'm using libmesa-cvs to get rid of the initial problem I posted
for (sizeof()), but still direct rendering is off. From Xorg.0.log:

...
(II) LoadModule: "glx"
(II) Loading /usr/X11R6/lib/modules/extensions/libglx.a
(II) Module glx: vendor="X.Org Foundation"
        compiled for 6.8.2, module version = 1.0.0
        ABI class: X.Org Server Extension, version 0.2
(II) Loading sub module "GLcore"
(II) LoadModule: "GLcore"
(II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a
Skipping "/usr/X11R6/lib/modules/extensions/libGLcore.a:m_debug_clip.o": No
symbols found
Skipping "/usr/X11R6/lib/modules/extensions/libGLcore.a:m_debug_norm.o": No
symbols found
Skipping "/usr/X11R6/lib/modules/extensions/libGLcore.a:m_debug_xform.o": No
symbols found
(II) Module GLcore: vendor="X.Org Foundation"
        compiled for 6.8.2, module version = 1.0.0
        ABI class: X.Org Server Extension, version 0.2
(II) Loading extension GLX
(II) LoadModule: "dri"
(II) Loading /usr/X11R6/lib/modules/extensions/libdri.a
(II) Module dri: vendor="X.Org Foundation"
        compiled for 6.8.2, module version = 1.0.0
        ABI class: X.Org Server Extension, version 0.2
(II) Loading sub module "drm"
(II) LoadModule: "drm"
(II) Loading /usr/X11R6/lib/modules/linux/libdrm.a
(II) Module drm: vendor="X.Org Foundation"
        compiled for 6.8.2, module version = 1.0.0
        ABI class: X.Org Server Extension, version 0.2
(II) Loading extension XFree86-DRI
...
(II) RADEON(0): [drm] installed DRM signal handler
(II) RADEON(0): [DRI] installation complete
(II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers
(II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers
(II) RADEON(0): [drm] dma control initialized, using IRQ 16
(II) RADEON(0): [drm] Initialized kernel GART heap manager, 5111808
(II) RADEON(0): Direct rendering enabled
...

Any hints?

cheers

I found where the problem is. I have libstd++6, while the entire glx subsystem
needs libstd++5. libstd++5 should be a needed package when installing xorg.

(In reply to comment #9)
> I found where the problem is. I have libstd++6, while the entire glx subsystem
> needs libstd++5. libstd++5 should be a needed package when installing xorg.

Please explain how you arrived at this conclusion. The only relevant component
which uses libstdc++5 is xorg-driver-fglrx, which depends on it. Are you using
that driver? It is also possible that one of the third-party components you are
using created this situation. Other Breezy users are successfully using direct
rendering without installing additional packages.

Created an attachment (id=3955)
Installed packages

Created an attachment (id=3956)
xorg configuration file

Premises
I'm using a freshly installed breezy on amd64, not a hoary dist-upgraded to
breezy. At the moment I don't have any source compiled library or application,
but I'm just using main/universe/multiverse breezy repositories.

Since I wasn't able to use the radeon driver with direct rendering on my
radeon9200, I switched to the fglrx driver. As with the radeon driver,
Xorg.0.log showed me direct rendering was successfully initialized, but glxinfo
was saying me the opposite ("Direct rendering: No"). Using LIBGL_VERBOSE=debug,
before the command, didn't add any useful information. So I straced glxinfo to
see if there was something wrong with it, and I noticed it tried to open
libstdc++5 without success. Once the library was installed, direct rendering was
working.

Anyway since I want to use the opensource driver I tried to switch to it again,
but still Xorg.0.log was saying everything was right, while direct rendering was
not enabled.
When I switched to breezy and found the error, I googled for it and found the
link I posted initially:

https://bugs.freedesktop.org/show_bug.cgi?id=4297

 So I downloaded the mesa libs from cvs, compiled them and I effectively found
the "ERROR! sizeof(RADEONDRIRec).." went away, but still direct rendering was
not enabled. I removed the cvs mesa libs and the error came again.

 For completeness I'll attach the list of packages I have and my xorg.conf. I'm
here for whateverelse you will need.

 Cheers.

if you can still reproduce this with a clean (no-fglrx, up-to-date packages)
system, I'd be very interested to hear it.

I have the same problem, i.e. glxinfo gives
    ERROR! sizeof(RADEONDRIRec) does not match passed size from device driver
It's a completely fresh, standard desktop install of 5.10 Breezy preview on a new amd64 dual-core
machine with a radeon 9200se video card. When I saw this page, I tried upgrading to the latest
xserver-xorg packages, so I started synaptic, added all the update repositories for Breezy 5.10,
and installed all updates. I now have xserver-xorg-* version 6.8.2.72. Rebooted, and still the
same problem persists.

Sorry for the long delay. I have updated the xorg to version 6.8.2-77 and

ERROR! sizeof(RADEONDRIRec) does not match passed size from device driver

 has disappeared. There's a new bug though affecting at least r200_dri.so file.
When I run glxinfo it displays:

LIBGL_DEBUG=verbose glxinfo
name of display: :0.0
libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0)
libGL: OpenDriver: trying /usr/lib/dri/r200_dri.so
drmOpenByBusid: Searching for BusID pci:0000:01:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 4, (OK)
drmOpenByBusid: drmOpenMinor returns 4
drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
libGL error: Can't open configuration file /etc/drirc: No such file or directory.
libGL error: Can't open configuration file /home/little/.drirc: No such file or
directory.

 and it stops here, not returning to shell, using CPU at 100%. I wanted to find
out more, so I run gdb glxinfo and I found something odd. The application is
stuck on the r200_dri.so library function driUtilUpdateDrawableInfo () which
loops endlessly. Debug session and listing follows:

...
name of display: :0.0
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGINT, Interrupt.
[Switching to Thread 46912518398368 (LWP 8490)]
0x00002aaaac01db32 in __driUtilUpdateDrawableInfo ()
---Type <return> to continue, or q <return> to quit---
   from /usr/lib/dri/r200_dri.so
(gdb) disassemble
...
0x00002aaaac01db2f <__driUtilUpdateDrawableInfo+655>: mov 0x40(%rdx),%eax
0x00002aaaac01db32 <__driUtilUpdateDrawableInfo+658>: mov 0x40(%rdx),%eax
0x00002aaaac01db35 <__driUtilUpdateDrawableInfo+661>: jmp 0x2aaaac01db2f
<__driUtilUpdateDrawableInfo+655>

 If you look at these lines of code, you notice the jump goes two instructions
above, forever. Tomorrow I'll look in the sources to see what could be wrong
here. Every 3D-accelerated application stucks at that point.

 cheers.

the ... hell? will put some packages up to try a bit later with lower
optimisations: i suspect gcc being crap.

does http://people.ubuntu.com/~daniels/libgl1-mesa-dri_6.3.2-0ubuntu7_i386.deb
fix this?

 I'm sorry I'm on amd64, so I think I shouldn't try that package.

 cheers.

(In reply to comment #16)
> 0x00002aaaac01db2f <__driUtilUpdateDrawableInfo+655>: mov 0x40(%rdx),%eax
> 0x00002aaaac01db32 <__driUtilUpdateDrawableInfo+658>: mov 0x40(%rdx),%eax
> 0x00002aaaac01db35 <__driUtilUpdateDrawableInfo+661>: jmp 0x2aaaac01db2f
> <__driUtilUpdateDrawableInfo+655>
>
> If you look at these lines of code, you notice the jump goes two instructions
> above, forever. Tomorrow I'll look in the sources to see what could be wrong
> here. Every 3D-accelerated application stucks at that point.

 This code is in the dri_util.c file in mesa-6.3.2/src/mesa/drivers/dri/common.
In __driUtilUpdateDrawableInfo method, among other things, there's this code:
 ...
    if (!__driFindDrawable(psp->drawHash, pdp->draw) ||
        ! (*dri_interface->getDrawableInfo)(pdp->display, pdp->screen, pdp->draw
,
                          &pdp->index, &pdp->lastStamp,
                          &pdp->x, &pdp->y, &pdp->w, &pdp->h,
                          &pdp->numClipRects, &pdp->pClipRects,
                          &pdp->backX,
                          &pdp->backY,
                          &pdp->numBackClipRects,
                          &pdp->pBackClipRects )) {
        /* Error -- eg the window may have been destroyed. Keep going
         * with no cliprects.
         */
        pdp->pStamp = &pdp->lastStamp; /* prevent endless loop */
        pdp->numClipRects = 0;
        pdp->pClipRects = NULL;
        pdp->numBackClipRects = 0;
        pdp->pBackClipRects = NULL;
    }
    else
       pdp->pStamp = &(psp->pSAREA->drawableTable[pdp->index].stamp);

    DRM_SPINLOCK(&psp->pSAREA->drawable_lock, psp->drawLockID);
}

The "pdp->pStamp = &pdp->lastStamp; /* prevent endless loop */" maybe is not
working, since endless loop is not prevented. I've tryed to recompile sources (I
got them with apt-get source libgl1-mesa-dri) with -O0, but it still stops
there. I don't know anything about DRI so I'm not able to change the code
significantly.

 hints?

(In reply to comment #16)

> LIBGL_DEBUG=verbose glxinfo
> name of display: :0.0
> libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0)
> libGL: OpenDriver: trying /usr/lib/dri/r200_dri.so
> drmOpenByBusid: Searching for BusID pci:0000:01:00.0
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 4, (OK)
> drmOpenByBusid: drmOpenMinor returns 4
> drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
> libGL error: Can't open configuration file /etc/drirc: No such file or directory.
> libGL error: Can't open configuration file /home/little/.drirc: No such file or
> directory.
>
> and it stops here, not returning to shell, using CPU at 100%. I wanted to find
> (...)
> here. Every 3D-accelerated application stucks at that point.

I'm having exactly the same problem. Xorg.log says that direct rendering is
enabled, but glxinfo and all other gl programs fail. Everything was working fine
in Hoary.
I'm also on amd64 and I have an ati 9250.

(In reply to comment #20)
> (In reply to comment #16)
> > 0x00002aaaac01db2f <__driUtilUpdateDrawableInfo+655>: mov 0x40(%rdx),%eax
> > 0x00002aaaac01db32 <__driUtilUpdateDrawableInfo+658>: mov 0x40(%rdx),%eax
> > 0x00002aaaac01db35 <__driUtilUpdateDrawableInfo+661>: jmp 0x2aaaac01db2f
> > <__driUtilUpdateDrawableInfo+655>
> >
> > If you look at these lines of code, you notice the jump goes two instructions
> > above, forever. Tomorrow I'll look in the sources to see what could be wrong
> > here. Every 3D-accelerated application stucks at that point.
>
> This code is in the dri_util.c file in mesa-6.3.2/src/mesa/drivers/dri/common.
> In __driUtilUpdateDrawableInfo method, among other things, there's this code:
> ...
> DRM_SPINLOCK(&psp->pSAREA->drawable_lock, psp->drawLockID);
> }
...
>
> hints?
>

I managed to track down what's happening here. Fortunatly the fix is
simple. The problem is in the file "/usr/include/xf86drm.h" from the
libdrm-dev package. This file is where dri_util.c gets its definition
of DRM_SPINLOCK. DRM_SPINLOCK gets expanded into an endless loop
because part of the code is behind an "#if defined (__AMD64__)" and
__AMD64__ is not defined by gcc-4. The symbol to __amd64__ is defined
by gcc-4. Applying the following patch to "/usr/include/xf86drm.h" and
rebuilding the libgl1-mesa-dri package fixes the problem, mesa-dri now
works as expected.

--- xf86drm.h.orig 2005-11-06 15:10:25.000000000 -0600
+++ xf86drm.h 2005-11-06 15:10:51.000000000 -0600
@@ -287,7 +287,7 @@
 #define DRM_LOCK_CONT 0x40000000U /**< Hardware lock is contended */

 #if defined(__GNUC__) && (__GNUC__ >= 2)
-# if defined(__i386) || defined(__AMD64__)
+# if defined(__i386) || defined(__amd64__)
                                /* Reflect changes here to drmP.h */
 #define DRM_CAS(lock,old,new,__ret) \
        do { \

oooh, excellent. thanks.

(In reply to comment #22)

Works for me. Many thanks!

fixicated in dapper