problems with X after upgrading xorg-server and nvidia-driver/nouveau

[Robert Noland]

On Tue, 2009-08-18 at 17:09 -0500, Rick C. Petty wrote:
> On Tue, Aug 18, 2009 at 07:46:28AM -0500, Robert Noland wrote:
> > On Mon, 2009-08-17 at 10:35 -0500, Rick C. Petty wrote:
> > > 
> > > ~~~  From dmesg.boot:  ~~~
> > > 
> > > drm0: <NVidia Display Adapter> on vgapci0
> > > panic: resource_list_alloc: resource entry is busy
> > > cpuid = 1
> > > KDB: stack backtrace:
> > > db_trace_self_wrapper(c0bb1b43,e876a7c4,c07f9ae9,c0bd34c8,1,...) at 0xc0499c26 = db_trace_self_wrapper+0x26
> > > kdb_backtrace(c0bd34c8,1,c0bb16cd,e876a7d0,1,...) at 0xc08265b9 = kdb_backtrace+0x29
> > > panic(c0bb16cd,1,0,c0cec438,0,...) at 0xc07f9ae9 = panic+0x119
> > 
> > This panic appears to be during irq resource allocation.  I'm not sure
> > how this occurs.  I haven't seen this issue reported before.  Does this
> > happen if you manually kldload nouveau.ko from the console, without
> > starting X?
> 
> That was happening when I loaded the module manually, before starting X.  I
> was able to get it working when I loaded it from loader.conf instead of
> directly.  After that the reported problems went away; I can't seem to
> reproduce this now.  Here are some other notes.
> 
> The first panic occured after I uninstalled nvidia-driver but didn't unload
> nvidia.ko first.  That one made sense.  After a reboot, there was no nvidia
> driver to load and yet the panic still happened.  After a couple more
> reboots, I was able to kldload nouveau.ko from the console without having
> to do it in the loader.conf.  Additionally, I played around with nouveau
> and nvidia together..  You can kldload nvidia if nouveau is already loaded
> but the reverse is not true.  Probably nouveau should behave better in
> this case, or perhaps refuse to load if nvidia is loaded.  Regardless,
> nvidia won't properly initialize because of resource allocation problems if
> nouveau is present, which makes sense, but at least it doesn't panic.
> 
> Another thing I noticed when using nouveau is that sometimes X just crashes
> for no apparent reason.  This happens more often when trying to use GL.  A
> warm reboot seems to fix the problem for awhile and GL apps just work,
> albeit very slowly (as is expected).  But every so often X crashes with no
> reported error messages (either on the console or in Xorg.0.log).  However,
> xf86-video-nouveau-0.0.10.20090728 was significantly more stable than
> nvidia-driver-180.29 on xorg-server-1.6.1,1.
> 
> After being fed up (who can work when X crashes every 5-60 seconds?), I
> decided to downgrade to xorg-server-1.5.3_7,1 and nvidia-driver-180.29.
> This seems to work just fine, even using the latest libraries (X11, GL,
> GLU, etc.) except that I had to downgrade to xf86-input-keyboard-1.2.2_1
> and xf86-input-mouse-1.2.3_1.  No more SEGVs for me now.
> 
> Is there a procedure for diagnosing X crashes on FreeBSD?  I could try to
> build everything with -g and inspect core files.  I was just hoping there
> was a better way.

Unfortunately, it is pretty ugly on all platforms.  There are numerous
components involved, the Xserver all of it's drivers and libraries,
libdrm which provides the drm API to userland, the actual drm kernel
drivers and all of the Mesa ports for GL.

Things that involve lockups or panics are generally drm, libdrm or DDX
driver.  Things that involve rendering problems generally fall more into
the DDX or Mesa territory, but not always.

The basic arsenal is DDB/kgdb for the kernel side.  Serial console is
also often useful, since usually lockups are also panics that you just
can't see.  gdb on the userland side.  Lots of printf's enabled with
various debugging knobs...

robert.

> -- Rick C. Petty
> _______________________________________________
> freebsd-x11 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-unsubscribe at freebsd.org"
-- 
Robert Noland <rnoland at FreeBSD.org>
FreeBSD