This build failure is caused by recent change in linux kernel:

$ git show 07613ba2f464f59949266f4337b75b91eb610795|head
commit 07613ba2f464f59949266f4337b75b91eb610795
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri Jun 12 14:11:41 2009 +1000

    agp: switch AGP to use page array instead of unsigned long array


And the drm tree has not been updated wrt these changes.

At least Nouveau developers will not fix this, since Nouveau is moving to a kernel tree. Please, see http://nouveau.freedesktop.org/wiki/InstallDRM for instructions, if you are compiling for Nouveau.

Seems you are building against 2.6.31-rc1. I would suggest waiting for -rc2, the -rc1 kernel is said to be in a bad shape. Anyway, use the master branch of the Nouveau kernel tree for these kernels.

Only time will tell if anybody still cares about drm.git linux-core.

Hi to all,
         Thank you for solving that perticular problem,but I have a new one now.I've got the latest kernel for Fedora Rawhide(2.6.31-0.62.rc2.git4.fc12.i586).I also downloaded the unnamed linux-26 kernel from git,and build it according to the instructions from the wiki.Along with the D.R.M from git,(mesa complains if I uninstall it)and just do a ./configure(with my options),make and make install with that repository.

I build the git version of Mesa using ./configure --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --datadir=/usr/share --sysconfdir=/etc --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --mandir=/usr/share/man --docdir=/usr/share/doc --enable-selinux --x-libraries=/usr/lib --enable-32-bit --enable-xcb --enable-gallium-nouveau --with-x --with-dri-driverdir=/usr/lib/dri --with-xorg-driver-dir=/usr/lib/xorg/modules/drivers --with-state-trackers=dri,egl,xorg,glx,vega --enable-motif --enable-gl-osmesa --with-osmesa-bits=32 --disable-gallium-intel --disable-gallium-radeon --with-expat=/usr/lib --with-demos=xdemos,demos,trivial,tests --with-dri-drivers=swrast,ffb,mga,sis then gmake and gmake install,that builds fine.I also do the usual ./configure make and make install with the xf86-video-nouveau source code from git.

Everything seems fine until I try to run glxgears,I open it with konsole,but as soon as I do that,the system totally locks up! I have to do a hard re-set before I can get back my desktop.My Graphics card is a Nvidia Gegorce 6,800 G.T (NV40) my monitor is a A.D.I Microscan G1,000 .

I ran a Fedora 11 Live cd,and when I run glxgears from there it runs fine.

I've looked in the /var/log directory. Xorg.0.log seems fine,but when I looked in messages,I found this output:

Jul 12 16:55:50 mernivia kernel:
Jul 12 16:55:50 mernivia kernel: =======================================================
Jul 12 16:55:50 mernivia kernel: [ INFO: possible circular locking dependency detected ]
Jul 12 16:55:50 mernivia kernel: 2.6.31-0.62.rc2.git4.fc12.i586 #1
Jul 12 16:55:50 mernivia kernel: -------------------------------------------------------
Jul 12 16:55:50 mernivia kernel: X/1072 is trying to acquire lock:
Jul 12 16:55:50 mernivia kernel: (&mm->mmap_sem){++++++}, at: [<c04d51b4>] might_fault+0x56/0xa4
Jul 12 16:55:50 mernivia kernel:
Jul 12 16:55:50 mernivia kernel: but task is already holding lock:
Jul 12 16:55:50 mernivia kernel: (&dev->struct_mutex){+.+.+.}, at: [<f874c197>] nouveau_gem_ioctl_pushbuf+0x1cc/0x7cd [nouveau]
Jul 12 16:55:50 mernivia kernel:
Jul 12 16:55:50 mernivia kernel: which lock already depends on the new lock.
Jul 12 16:55:50 mernivia kernel:
Jul 12 16:55:50 mernivia kernel:
Jul 12 16:55:50 mernivia kernel: the existing dependency chain (in reverse order) is:
Jul 12 16:55:50 mernivia kernel:
Jul 12 16:55:50 mernivia kernel: -> #2 (&dev->struct_mutex){+.+.+.}:
Jul 12 16:55:50 mernivia kernel:       [<c046f1f5>] __lock_acquire+0x996/0xb08
Jul 12 16:55:50 mernivia kernel:       [<c046f41e>] lock_acquire+0xb7/0xeb
Jul 12 16:55:50 mernivia kernel:       [<c0815537>] __mutex_lock_common+0x43/0x32b
Jul 12 16:55:50 mernivia kernel:       [<c0815912>] mutex_lock_nested+0x41/0x5a
Jul 12 16:55:50 mernivia kernel:       [<f868a990>] drm_vm_open+0x38/0x5c [drm]
Jul 12 16:55:50 mernivia kernel:       [<c0441c50>] dup_mm+0x248/0x32e
Jul 12 16:55:50 mernivia kernel:       [<c04427fb>] copy_process+0xa71/0x112e
Jul 12 16:55:50 mernivia kernel:       [<c0442fef>] do_fork+0x137/0x2e3
Jul 12 16:55:50 mernivia kernel:       [<c0402327>] sys_clone+0x35/0x4d
Jul 12 16:55:50 mernivia kernel:       [<c0403a5c>] syscall_call+0x7/0xb
Jul 12 16:55:50 mernivia kernel:       [<ffffffff>] 0xffffffff
Jul 12 16:55:50 mernivia kernel:
Jul 12 16:55:50 mernivia kernel: -> #1 (&mm->mmap_sem/1){+.+.+.}:
Jul 12 16:55:50 mernivia kernel:       [<c046f1f5>] __lock_acquire+0x996/0xb08
Jul 12 16:55:50 mernivia kernel:       [<c046f41e>] lock_acquire+0xb7/0xeb
Jul 12 16:55:50 mernivia kernel:       [<c045fb63>] down_write_nested+0x4d/0x9c
Jul 12 16:55:50 mernivia kernel:       [<c0441ac0>] dup_mm+0xb8/0x32e
Jul 12 16:55:50 mernivia kernel:       [<c04427fb>] copy_process+0xa71/0x112e
Jul 12 16:55:50 mernivia kernel:       [<c0442fef>] do_fork+0x137/0x2e3
Jul 12 16:55:50 mernivia kernel:       [<c0402327>] sys_clone+0x35/0x4d
Jul 12 16:55:50 mernivia kernel:       [<c0403a5c>] syscall_call+0x7/0xb
Jul 12 16:55:50 mernivia kernel:       [<ffffffff>] 0xffffffff
Jul 12 16:55:50 mernivia kernel:
Jul 12 16:55:50 mernivia kernel: -> #0 (&mm->mmap_sem){++++++}:
Jul 12 16:55:50 mernivia kernel:       [<c046f0fc>] __lock_acquire+0x89d/0xb08
Jul 12 16:55:50 mernivia kernel:       [<c046f41e>] lock_acquire+0xb7/0xeb
Jul 12 16:55:50 mernivia kernel:       [<c04d51d1>] might_fault+0x73/0xa4
Jul 12 16:55:50 mernivia kernel:       [<c05f7f24>] copy_to_user+0x41/0x12b
Jul 12 16:55:50 mernivia kernel:       [<f874c48b>] nouveau_gem_ioctl_pushbuf+0x4c0/0x7cd [nouveau]
Jul 12 16:55:50 mernivia kernel:       [<f8685f85>] drm_ioctl+0x21a/0x2c1 [drm]
Jul 12 16:55:50 mernivia kernel:       [<c0501d17>] vfs_ioctl+0x66/0x91
Jul 12 16:55:50 mernivia kernel:       [<c05022c8>] do_vfs_ioctl+0x4ba/0x50b
Jul 12 16:55:50 mernivia kernel:       [<c050236e>] sys_ioctl+0x55/0x86
Jul 12 16:55:50 mernivia kernel:       [<c0403a5c>] syscall_call+0x7/0xb
Jul 12 16:55:50 mernivia kernel:       [<ffffffff>] 0xffffffff
Jul 12 16:55:50 mernivia kernel:
Jul 12 16:55:50 mernivia kernel: other info that might help us debug this:
Jul 12 16:55:50 mernivia kernel:
Jul 12 16:55:50 mernivia kernel: 1 lock held by X/1072:
Jul 12 16:55:50 mernivia kernel: #0:  (&dev->struct_mutex){+.+.+.}, at: [<f874c197>] nouveau_gem_ioctl_pushbuf+0x1cc/0x7cd [nouveau]
Jul 12 16:55:50 mernivia kernel:
Jul 12 16:55:50 mernivia kernel: stack backtrace:
Jul 12 16:55:50 mernivia kernel: Pid: 1072, comm: X Not tainted 2.6.31-0.62.rc2.git4.fc12.i586 #1
Jul 12 16:55:50 mernivia kernel: Call Trace:
Jul 12 16:55:50 mernivia kernel: [<c08140c4>] ? printk+0x22/0x36
Jul 12 16:55:50 mernivia kernel: [<c046e547>] print_circular_bug_tail+0x68/0x84
Jul 12 16:55:50 mernivia kernel: [<c046f0fc>] __lock_acquire+0x89d/0xb08
Jul 12 16:55:50 mernivia kernel: [<c046f41e>] lock_acquire+0xb7/0xeb
Jul 12 16:55:50 mernivia kernel: [<c04d51b4>] ? might_fault+0x56/0xa4
Jul 12 16:55:50 mernivia kernel: [<c04d51b4>] ? might_fault+0x56/0xa4
Jul 12 16:55:50 mernivia kernel: [<c04d51d1>] might_fault+0x73/0xa4
Jul 12 16:55:50 mernivia kernel: [<c04d51b4>] ? might_fault+0x56/0xa4
Jul 12 16:55:50 mernivia kernel: [<c05f7f24>] copy_to_user+0x41/0x12b
Jul 12 16:55:50 mernivia kernel: [<f874c48b>] nouveau_gem_ioctl_pushbuf+0x4c0/0x7cd [nouveau]
Jul 12 16:55:50 mernivia kernel: [<f8685f85>] drm_ioctl+0x21a/0x2c1 [drm]
Jul 12 16:55:50 mernivia kernel: [<f874bfcb>] ? nouveau_gem_ioctl_pushbuf+0x0/0x7cd [nouveau]
Jul 12 16:55:50 mernivia kernel: [<c0409581>] ? sched_clock+0x9/0xd
Jul 12 16:55:50 mernivia kernel: [<c046c705>] ? lock_release_holdtime+0x39/0x143
Jul 12 16:55:50 mernivia kernel: [<c04d8208>] ? do_wp_page+0x5df/0x6aa
Jul 12 16:55:50 mernivia kernel: [<c042c20a>] ? kunmap_atomic+0x6d/0xa8
Jul 12 16:55:50 mernivia kernel: [<c0501d17>] vfs_ioctl+0x66/0x91
Jul 12 16:55:50 mernivia kernel: [<c05022c8>] do_vfs_ioctl+0x4ba/0x50b
Jul 12 16:55:50 mernivia kernel: [<c08193ab>] ? do_page_fault+0x2aa/0x2fa
Jul 12 16:55:50 mernivia kernel: [<c0409581>] ? sched_clock+0x9/0xd
Jul 12 16:55:50 mernivia kernel: [<c08193ab>] ? do_page_fault+0x2aa/0x2fa
Jul 12 16:55:50 mernivia kernel: [<c0492c1f>] ? audit_syscall_entry+0x135/0x168
Jul 12 16:55:50 mernivia kernel: [<c050236e>] sys_ioctl+0x55/0x86
Jul 12 16:55:50 mernivia kernel: [<c040c435>] ? syscall_trace_enter+0xea/0x10f
Jul 12 16:55:50 mernivia kernel: [<c0403a5c>] syscall_call+0x7/0xb
Jul 12 16:55:57 mernivia kernel: kdm_greet used greatest stack depth: 5084 bytes left
Jul 12 16:56:22 mernivia pulseaudio[1525]: pid.c: Stale PID file, overwriting.
Jul 12 16:56:24 mernivia kernel: fuse init (API version 7.12)

I hope that is useful,I tried to use gdb to find the error in glxgears,but it would just lock up on me.If you can tell me the best way to track down those error messages,that would be helpful and I should be to report back the information.

Regards,
       STEVE555

Now you are getting off-topic for this bug. Mesa with Nouveau acceleration is a completely unsupported combination at the time, and we know it is now broken more than before. Somehow I doubt that even F11 would pack Nouveau 3D acceleration, so you were getting software rendering, which should work.

I think you should build Mesa without Nouveau Gallium3D, and close this bug, since it is not about building DRM kernel modules from drm.git anymore.

You are welcome to file a new bug about the lockdep warning, and even better if you can reproduce it without resorting to Mesa Gallium3D. It is a kernel (DRM) bug (probably nouveau), not a glxgears or Mesa bug.

Hi there,
        I am sorry about that,I shouldn't have added this new problem to this bug report.I have had some success in the past to get the all three pieces of source code"working"(all thanks to the developers advice and doing a lot of browsing and forum posting)I'm getting the impression that the A.T.I and Nouveau code seems to be "forking"(i.e,going their separate ways)and I think that it is a shame .I can pull out my current Nvidia card and replace it with my very old A.T.I 9,200(Rv 280?) and use that instead,but that maybe more hassle than it could be worth.

I wish I knew about C++ and the inner workings of the stack,but I think that would be too much of a steep learning curve.

I'd like to thank you very much for your help anyway.

Regards,
       STEVE555