Created attachment 5961 [details]
$strace glxinfo

Created attachment 5962 [details]
dmesg with debug of drm.ko enabled

Same here on an Athlon-XP 1800+ (32bit) with an G550 (AGP).

Felix, did you find a workaround meanwhile?

markus

Created attachment 6102 [details]
another dmesg log

Nope. I attached a syslog from my box - this is where the app hangs for me:

Jul  2 05:23:25 alkoholix kernel: [drm:drm_lock] 3 (pid 8368) requests lock
(0x80000001), flags = 0x00000000

(can't find that one in your log?)

ltrace -S glxinfo ends with this:

<... glXCreateContext resumed> )					       
		  = 0x80544b8
glXMakeCurrent(0x804d008, 0x1000002, 0x80544b8, 1, 100 <unfinished ...>
SYS_write(3, "\220\003\006", 36)					       
		  = 36
SYS_read(3, "\001", 32) 						       
		  = 32
SYS_write(3, "\222\t\003", 12)						       
		  = 12
SYS_read(3, "\001a\032", 32)						       
		  = 32
SYS_read(3, "", 4)							       
		  = 4
SYS_futex(0xb7ee36d0, 1, 0x7fffffff, 0, 0x8472660)			       
		  = 0
SYS_ioctl(4, 0x4008642a, 0xbfabce68, 0xbfabce68, 4)			       
		  = -512
--- SIGINT (Interrupt) ---

Oh, and another G550 user I know is having the same problem (or the other way
around - I dunno of any G550 user who is not :).

Seems I have a similar, perhaps the same, problem...
Only it's a G450 and the programs hang without any warning from libGL.

The machine is an Athlon Thunderbird with a G450.

My configuration is:
Linux 2.6.17
Xorg 7.1

And I use up to date external drm kernel modules:
/dev/dri/card0
  Version information:
    Name: mga
    Version: 3.2.2
    Date: 20060319
    Desc: Matrox G200/G400


If I enable DRI and GLX, I get DRI enabled, but all GL programs hang or display
black windows.

In particular, "glxgears" displays a black window, "mplayer -vo gl" hangs, and
glxinfo stops after printing its first line "name of display: :0.0".

Without direct rendering, all works as expected.

I also suffer from bug #6884 , which could be a related issue...

[]s, ale

ok, absolutely strange but maybe it helps anyone -- at least to amuse :

if i do a $glxinfo in one xterm i get:
name of display: :0.0
libGL warning: 3D driver claims to not support visual 0x4b

-- program hangs. except i open a second terminal window and do exactly the 
same: $glxinfo then the first one(!) finishes with the attached output. nice.

markus

Created attachment 6145 [details]
$ LIBGL_DEBUG=verbose glxinfo -- executed twice simultaniously

Matrox G400 card here, Gentoo and Xorg server 1.1.0

$ LIBGL_DEBUG=verbose glxinfo
name of display: :0.0
libGL: XF86DRIGetClientDriverName: 1.4.1 mga (screen 0)
libGL: OpenDriver: trying /usr/lib/dri/tls/mga_dri.so
libGL: OpenDriver: trying /usr/lib/dri/mga_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 warning: 3D driver claims to not support visual 0x4b
libGL error:
Can't open configuration file /etc/drirc: No such file or directory.
libGL error:
Can't open configuration file /home/kimmos/.drirc: No such file or directory.

Trying an example /etc/drirc removes the first complaint, and linking ~/.drirc
to it removes the second complaint.  Otherwise the situation did not improve.

<driconf>
   <device screen="0" driver="mga">
      <application name="all">
         <!-- Always synchronize with vertical refresh to avoid tearing -->
         <option name="vblank_mode" value="3"/>
      </application>
      <application name="glxgears" executable="glxgears">
         <!-- glxgears should not synchronize with vertical refresh, show full
fps -->
         <option name="vblank_mode" value="0"/>
      </application>
   </device>
</driconf>

I'm not sure I'm seeing the same bug. glxinfo etc are also stuck in
drmGetLock(), but I'm also seeing this in Xorg.log:

DRIUnlock called when not locked

Are you guys seeing this, too, or is this another issue?

If anyone has some free time on their hands, it would help if you could use the
xorg-server git repository to build the code from January perhaps (and the mga
driver from that time) to see whether it worked back then.

If it did, use git bisect to find the commit that introduced the breakage.

So far I only verified that it's not fe0c838b5d8bc8d9cf5a686bb7d3e90682d2d19a
that causes this :/

I've bisected the server now; the breakage was introduced by commit
c3342c8000f6d2bfb61e2cf95e028d11b59698fa (AIGLX merge).

Kristian, can you have a look at this?

See this thread for some discussion about the problem:
http://marc.theaimsgroup.com/?l=dri-devel&m=115407405219563&w=2

Fixed in bde592047cd62194d7ef67520a9fdbaf269a8b90.