A xlog or a backtrace, anything to indicate what went wrong is needed.

These are the final lines from X:

nv_output_restore is called
nv_output_restore is called
nv_output_restore is called
pre-Owner: 0x0
post-Owner: 0x0
pre-Owner: 0x0
post-Owner: 0x0
(EE) NOUVEAU(0): [DRI] Locking deadlock.
        Already locked with context 157577356,
        trying to lock with context 2.
(EE) NOUVEAU(0): Error creating device

Fatal server error:
AddScreen/ScreenInit failed for driver 0

Created attachment 13418 [details]
Xorg.0.log

The crash is also present without RandR 1.2 on this card. A case of bad testing on my part. Sorry.

Same problem with Gentoo ~amd64, nVidia 7600 GS. Lastest x11-drm, libdrm and xf86-video-nouveau. If is server restarted with CTRL-ALT-BACKSPACE, not crash. If is ended with exit in failsafe mode, or Logout in KDE, then crash with same error in X.Org.0.log

Created attachment 15916 [details]
DMesg log

This file is quite long, but in the middle you can see some traces of nouveau driver doing some nasty things. I haven't cut the file because I think you prefer the whole message log.

I have the same issue, but I must admit that I am running Fedora 9 Beta and I am using the nouveau driver packaged for the distro:

xorg-x11-drv-nouveau-0.0.10-2.20080408git0991281.fc9.i386

X server crashes and won't run again (actually, I have to do a hard reboot because the console is not showing up, only some error messages on the screen and ALT+Fx doesn't work).

I've created an attachment with dmesg log, you can look for "nouveau" phrase and you will find a backtrace.

It shows something like this:

Apr 13 10:13:41 Tommy-PC kernel: Fixing recursive fault but reboot is needed!

And unfortunately it tells the truth:( I had to disable RHGB (Red Hat Graphical Boot, it starts X server to show the boot progress graphically and then restarts it and starts GDM). Because RHGB starts the X server, it won't run again and it won't show GDM.

Packages:

xorg-x11-server-Xorg-1.4.99.901-21.20080407.fc9.i386
[root@Tommy-PC tommy]# uname -r
2.6.25-0.218.rc8.git7.fc9.i686

And, arr, my card: GeForce 7100 GS. I have GeForce 8600GT laying on my desk, but haven't tested it yet.

I've seen this before, for someone reason it partially restarts while X is still running, i wonder if that is valid beheaviour.

s/someone/some

Created attachment 15930 [details] [review]
This is a very crude attempt, but it may work.

Please test this.

Can someone test this?

I'm afraid the patch is insufficient. I get this now:

(EE) [drm] Could not set DRM device bus ID.
(EE) NOUVEAU(0): [dri] DRIScreenInit failed.  Disabling DRI.

Fatal server error:
AddScreen/ScreenInit failed for driver 0


I'm in #nouveau if you have a quick update for me to test.

ossman has unusual and unexplainable problems, anyone else that can test?

I have the same problem.

I have tested the patch, and whenever the server restarts, it crashes, giving me the same message Ossman was getting, instead of the "deadlock" message.

(EE) [drm] Could not set DRM device bus ID.
(EE) NOUVEAU(0): [dri] DRIScreenInit failed.  Disabling DRI.

Fatal server error:
AddScreen/ScreenInit failed for driver 0

It would really help if someone who actually had the issue look at it, because this is not easy to do blindly.

I committed a few changes that might help, please try again.

Created attachment 17495 [details]
Syslog with "debug=1" in drm.ko

Tested with July 02 2008 drm/nouveau.
Loaded drm.ko with debug=1.

Created attachment 17496 [details]
Xorg log

Tested with July 02 2008 drm/nouveau
The problem still happens with me.

How I reproduced the bug:

Open X
DISPLAY=:0.0 xterm
"ctrl+c" to kill xterm.

Using the repro method in comment 19, I've pushed some stuff which now lets me regenerate without crashing, so anyone who was hitting this, please test.

The problem here is that for every mmap(2) (wrapped in the libdrm function drmMap), the kernel increases the refcount on the struct file associated with the drm file descriptor.  While we can happily call drmClose (which wraps close(2)), this only decreases the filp->f_count refcount by one, and the count needs to hit zero before the fops->release function (drm_release) is called to free all kernel-side resources.
Calling the release function also means that next time the DRM is opened the opener becomes DRM master, which is necessary for privileged ioctls to work on the next xserver generation.  The solution pushed is to drmUnmap (wrapping munmap(2)) all mappings made on the fd (i.e. the user channel, and all buffer objects).

AFAIK the fixes described in comment 20 fixed this.  Please reopen with Xorg.0.log and dmesg logs and preferably details of how to reproduce if you still hit this.