From owner-freebsd-x11@FreeBSD.ORG Tue Aug 18 22:25:07 2009 Return-Path: Delivered-To: x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71803106568B; Tue, 18 Aug 2009 22:25:07 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 2C07A8FC3D; Tue, 18 Aug 2009 22:25:06 +0000 (UTC) Received: from [192.168.1.4] (adsl-154-162-243.bna.bellsouth.net [68.154.162.243]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n7IMP3GS028596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Aug 2009 18:25:05 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: rick-freebsd2008@kiwi-computer.com In-Reply-To: <20090818220923.GA82219@keira.kiwi-computer.com> References: <20090817153513.GA25131@keira.kiwi-computer.com> <1250599588.1752.742.camel@balrog.2hip.net> <20090818220923.GA82219@keira.kiwi-computer.com> Content-Type: text/plain Organization: FreeBSD Date: Tue, 18 Aug 2009 17:24:57 -0500 Message-Id: <1250634297.62048.10.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: x11@freebsd.org, John Baldwin Subject: Re: problems with X after upgrading xorg-server and nvidia-driver/nouveau X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 22:25:07 -0000 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: 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" -- Robert Noland FreeBSD