Created attachment 87695 [details]
/var/log/messages

Elmar

Please try to provide more comprehensive picture of the issue rather than just "crashes regularely"
* output of dmesg as the issue happens. if X crashes you should be able to get back to VT and retrieve it :) Possibly even over ssh (if you prefer using gui)
* is this a regression ?
* "crashes regularely" is quite vague. Some steps to reproduce/trigger would be great
* to eliminate 3d/opengl interaction {re,}move the nouveau_vieux_dri.so


It would be great if you can spend a couple of minutes going through the bugs[1], faq[2] and trouble shooting[3] sections in the wiki

Cheers

[1] http://nouveau.freedesktop.org/wiki/Bugs/
[2] http://nouveau.freedesktop.org/wiki/FAQ/
[3] http://nouveau.freedesktop.org/wiki/TroubleShooting/

Well the crash has to do with enabling an external screen via the xrandr extension. If I boot from xinit via startkde into KDE then it does not crash unless I enable an external monitor (as done at me by default). Since enabling an external monitor is not supported until long (Bug 47556) this is not a regression; "crashes regularely" should mean "always; in any case.". Xorg.0.log and dmesg will follow; can and will also re-test without nouveau_vieux_dri.so.

kernel-3.11.3-1.1-default
libdmr2-2.4.46-3.2.2
libdrm-nouveau2-2.4.46-3.2.2
Mesa-9.2.1-61.4.1
Mesa-libGLESv2-2-9.2.1-61.4.1
DirectFB-Mesa-1.6.3-4.1.3

Created attachment 87737 [details]
dmesg (log_buf_len=1M)

Created attachment 87738 [details]
Xorg.0.log for dmesg

Well, without nouveau_vieux_dri.so it even crashes immediately on startkde rather than at the end of startkde as usual (can`t do without that file).

Can you get symbols + disassembly for that backtrace? Specifically the nouveau_drv bit of it. If you're unsure how to do that, let us know, and what distribution you're using, and we'll attempt to come up with some instructions.

damn openSUSE! It always installs outdated -debuginfo packages (https://bugzilla.novell.com/show_bug.cgi?id=845626). Can`t you recommend me another distribution with up-to-date factory and working debuginfo?

(In reply to comment #8)
> damn openSUSE! It always installs outdated -debuginfo packages
> (https://bugzilla.novell.com/show_bug.cgi?id=845626). Can`t you recommend me
> another distribution with up-to-date factory and working debuginfo?

$ osc getbinaries -d $DIR openSUSE:13.1 $PACKAGE standard $ARCHITECTURE $FILE
$ cd $DIR
$ sudo zypper in $(ls)

 Unfortunately that did not work as expected:
> osc getbinaries openSUSE:13.1 $PACKAGE standard $ARCHITECTURE $FILE
gives me the error message: Need either 1, 2 or 4 arguments (seems not implemented)
> osc getbinaries openSUSE:13.1 $PACKAGE standard $ARCHITECTURE
however re-downloads the whole package which can be installed via
> rpm -Uvh --force $PACKAGE
Nonetheless this does not give me debuginfo yet.
If I do an nm -s on the specified files it returns 'no symbols'; an rpm -ql shows that these packages do also not contain external debuginfo.

(In reply to comment #10)
>  Unfortunately that did not work as expected:
[...]
> Nonetheless this does not give me debuginfo yet.

Maybe you should provide valid values for variables:

osc getbinaries --debug -d debuginfo openSUSE:13.1 Mesa standard i586 Mesa-debuginfo-9.2.1-61.4.1.i586.rpm
osc getbinaries --debug -d debuginfo openSUSE:13.1 xorg-x11-driver-video-nouveau standard i586 xorg-x11-driver-video-nouveau-debuginfo-1.0.9-3.1.2.i586.rpm
osc getbinaries --debug -d debuginfo openSUSE:13.1 xorg-x11-server standard i586 xorg-x11-server-debuginfo-7.6_1.14.3-2.1.3.i586.rpm
osc getbinaries --debug -d debuginfo openSUSE:13.1 libdrm standard i586 libdrm2-debuginfo-2.4.46-3.2.2.i586.rpm
osc getbinaries --debug -d debuginfo openSUSE:13.1 libdrm standard i586 libdrm_nouveau2-debuginfo-2.4.46-3.2.2.i586.rpm
osc getbinaries --debug -d debuginfo openSUSE:13.1 libdrm standard i586 libkms1-debuginfo-2.4.46-3.2.2.i586.rpm

cd debuginfo

sudo zypper in $(ls)

Created attachment 87791 [details]
installed (debug) packages

debuginfo is installed now though the backtrace seems still little meaningful

Created attachment 87792 [details]
Xorg.0.log

Created attachment 87793 [details]
dmesg (log_buf_len=1M)

Please try this script to get a gdb backtrace:
http://www.x.org/wiki/Development/Documentation/ServerDebugging/#index6h2

Attach then only the file "Log written to: ..."

Created attachment 87830 [details]
gdb output of running Xorg (kernel 3.12.0-rc5-1-default)

Now that seems somehow useful though gdb still recommended more debuginfo.

did not succeed to install any of these additional debuginfos anyway except glibc, libstc++ and libudev which won`t help much.

To me it looks like a memory allocation issue as re-testing with a smaller external screen with low resolution did not yield any crash.

I /think/ I look @the same problem, during a different operation. I try to display an image larger than the screen using "display" (from imagemagick). The gdb backtrace from the core dump looks very similar just before it crashes:

#12 nouveau_exa_upload_to_screen (pdpix=0xb86cb578, x=0, y=0, w=4000, h=16, 
    src=0xb87b5268 "", src_pitch=16000) at ../../src/nouveau_exa.c:389
        pScrn = <optimized out>
        pNv = 0xb84516c0
        dst_pitch = 16000
        tmp_pitch = 16000
        cpp = 4
        i = <optimized out>
        bo = 0xb87da000
        dst = <optimized out>
        ret = 256000
        __func__ = "nouveau_exa_upload_to_screen"

(full bt will be uploaded). The display program does not scale down the image to screen resolution but displays the picture @original resolution and offers a thumbnail to select the part of the image to display.

I initially noticed this problem on debian stable (nouveau 1.0.1), I upgraded to nouveau 1.0.10, the bt now looks different, but the crash still happens.

Created attachment 94429 [details]
Backtrace for Comment #19

Will re-test this when you would give me a request to do so.

Resolved with x11-server-xorg-1.18.4-1.mga6(sta1) / 4.7.2.-desktop-1. Nouveau now succeeds in xinerama-ing two screens with 1024x768 and another with more than FullHD on my NV17M (GeForce4 420 Go).