# Nouveau Causes Segfault

## phobos13013

OK, so for the longest time I was using the nvidia driver to run my video on a very aging box; however, within the last few months... when running the nvidia driver my computer hung on boot with the "waiting for uevents to be processed" deal.  I tried falling back to older and older versions of nvidia, but to no avail.  Soooo, I switched to nouveau; now, i get constant segfaults whenever video is running whether it be streamed thru a browser or running on a media player.

Here is the end of output I am getting from Xorg on crash:

 *Quote:*   

> 
> 
> ...............
> 
> [   911.854] (EE) 12: /usr/bin/X (0x400000+0x112a38) [0x512a38]
> ...

 

Any ideas what this referring to?  I dont really know how to interpret this log.  Any other pertinent info needed to diagnosis?  Going to nvidia is not possible so i have to make it work with nouveau....

----------

## chithanh

This could be a VDPAU or other acceleration problem.

First thing you could try is upgrading to unstable mesa-10.4.2, xorg-server-1.16.3 and x86-video-nouveau-1.0.11

If the problem still happens, try disabling USE="vdpau" for mesa. As a last resort, boot with nouveau.noaccel=1 kernel parameter (but things will be slow then).

To get further help, you will need to obtain a proper backtrace from the X server to isolate the problem more. Build xorg-server with debug symbols (CFLAGS=-g FEATURES=splitdebug). Connect from another computer via ssh and attach gdb to your X server.

More instructions at http://www.x.org/wiki/Development/Documentation/ServerDebugging/

----------

## phobos13013

Chit!

  Great info thanks, will implement these suggestions and see what happens/post further progress or hiccups!

----------

## phobos13013

OK, well turns out not so great news.  At least no progress:

I tried to upgrade mesa/xorg-server/nouveau but there were just too many conflicts from dependicies to move forward with.  Many of them are in the x11 base or drivers and I don't know their current unstables let alone how to resolve them all.

I did re-emerge mesa with -vdpau but that didnt do the trick.  I wont set a kernel parameter thats just useless and kernel debugging is something I just dont have the time for as I have never tried it and thats a good week long progress.  Hoping a kernel or nouveau update solves this.

Willing to accept other suggestions, so bumping

----------

## chithanh

The following should be enough to allow an upgrade:

```
=app-admin/eselect-opengl-1.3.1-r1

=media-libs/libepoxy-1.2

=media-libs/mesa-10.4.2

=x11-libs/libXfont-1.5.0

=x11-libs/libdrm-2.4.58

=x11-base/xorg-drivers-1.16

=x11-base/xorg-server-1.16.3-r1

=x11-drivers/xf86-video-nouveau-1.0.11

=x11-proto/xproto-7.0.26

=x11-proto/glproto-1.4.17-r1

=x11-proto/fontsproto-2.1.3

```

Then run "emerge --oneshot --ask mesa xorg-server libXfont"

The kernel parameter I suggested you to try is just for isolating the issue.

----------

## phobos13013

Sweet, libXfont was the sticking point; will try thst one later, gotta run for the day.  I did try the --oneshot option for mesa alone but not the libXfont.

Thanks again and will let all know.

----------

## phobos13013

Wheeew,

  So I tried to run the blanket command with the newly included accept_keywords file (btw chit you didnt write ~amd64 next to all those packages but I got the drift  :Wink: ) and i still had a bunch of collisions and blocks, so I just went down that list one at a time.  When I finally got xorg-server installed it told me that you should/had to rebuild all x11-modules if coming from <1.16 which at that point I couldnt remember if i had or not but I think I did, so made that interlude "emerge @x11-modules-rebuild (although I think it was redundant because they had probably been rebuilt in that initial command).

ANYWAY, after that I got to mesa... now I have a problem.  It will not upgrade mesa to unstable without upgrading eselect-opengl to 1.3.1 BUT even the latest xorg-server and others require less than that (1.3.0 which is currently installed).  So I cannot upgrade mesa because of critical collision with eselect-opengl.  EDIT - WAS going to give it a go with just this upgraded setup, but it segfaulted within 5 mins.  If mesa is the key, any idea how to get through the eselect-opengl limitation?

Oh, and one other package that is blocking is emul-linux-x86-opengl.... I tried to activate the r1 version in accept_keywords but it wasnt enough to get rid of the block.  So its xorg-server and emul-opengl that is holding back mesa...

So, still stuck with a failed X

----------

## phobos13013

Bump.... Still crashing requiring hard reboot every five mins whenever video is played.

See above

----------

## phobos13013

OK, so this one is not solved but my suspicion is no longer centered on nouveau or vicarously mesa, xorg, etc.  I am on kernel 3.17 and I am fairly certain this is the dreaded lockup bug that plagued 3.17/3.18.  Why did this get let into the repositories if there is known/unresolved/unlocatable issues with this kernel?!  My life was fine until this damned thing entered my system.  I have tried backing down kernels but to no avail.  This is unresolved, still have the issue and until the kernel issue is sorted it seems i am stuck with an unusable gentoo.

----------

