From owner-freebsd-sparc64@FreeBSD.ORG Sun Nov 9 18:32:36 2008 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17A501065672 for ; Sun, 9 Nov 2008 18:32:36 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 9DECB8FC1A for ; Sun, 9 Nov 2008 18:32:35 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id mA9IWW5G076781; Sun, 9 Nov 2008 19:32:32 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id mA9IWWUc076780; Sun, 9 Nov 2008 19:32:32 +0100 (CET) (envelope-from marius) Date: Sun, 9 Nov 2008 19:32:32 +0100 From: Marius Strobl To: Ruben de Groot Message-ID: <20081109183232.GC76319@alchemy.franken.de> References: <20081103120215.GA32257@ei.bzerk.org> <20081103221111.GA8256@alchemy.franken.de> <20081105195630.GA52831@ei.bzerk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081105195630.GA52831@ei.bzerk.org> User-Agent: Mutt/1.4.2.3i Cc: sparc64@freebsd.org Subject: Re: kgdb on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2008 18:32:36 -0000 On Wed, Nov 05, 2008 at 08:56:30PM +0100, Ruben de Groot wrote: > On Mon, Nov 03, 2008 at 11:11:11PM +0100, Marius Strobl typed: > > > > After upgrading to 7.1-PRERELEASE last month I'm seeing some > > > spontaneous reboots with crash dumps on this Netra X1. How > > > can I debug this as kgdb seems not to be working? > > [...] > > > I've never had much luck with kgdb(1) on any arch and use > > devel/gdb53 which still has '-k' instead (for sparc64 just > > remove the BROKEN from the port Makefile; the problem > > leading to that one being added was fixed some time a go). > > The installation of gbd53 fails unfortunately with: > > gmake[1]: Leaving directory `/usr/ports/devel/gdb53/work/gdb-5.3/sparc64-portbld-freebsd7.1/libiberty' > gmake[1]: Entering directory `/usr/ports/devel/gdb53/work/gdb-5.3/libiberty' > rm -f libiberty.a pic/libiberty.a > sparc64-unknown-freebsd7.1-ar rc libiberty.a \ > regex.o cplus-dem.o cp-demangle.o md5.o alloca.o argv.o choose-temp.o concat.o dyn-string.o fdmatch.o fibheap.o floatformat.o fnmatch.o getopt.o getopt1.o getpwd.o getruntime.o hashtab.o hex.o lbasename.o make-temp-file.o objalloc.o obstack.o partition.o pexecute.o safe-ctype.o sort.o spaces.o splay-tree.o strerror.o strsignal.o ternary.o xatexit.o xexit.o xmalloc.o xmemdup.o xstrdup.o xstrerror.o > gmake[1]: sparc64-unknown-freebsd7.1-ar: Command not found > gmake[1]: *** [libiberty.a] Error 127 > gmake[1]: Leaving directory `/usr/ports/devel/gdb53/work/gdb-5.3/libiberty' > gmake: *** [all-libiberty] Error 2 > *** Error code 2 > > Stop in /usr/ports/devel/gdb53. Oh, apparently it has developed a new problem since the gcc34 problem was fixed in February, sorry... > > > For your purposes it's probably simpler to just build a > > kernel with debugger by adding "options DDB", "options KDB" > > and "makeoptions DEBUG=-g". Then when the kernel panics > > just enter "backtrace" on the console. With a X1 you > > most likely use serial console anyway so you can easily > > capture the output. > > I'll build a kernel with those options just in case. But > would rather not use it on this particular machine, as it is > a production server and should not be down for extended periods > of time. If you additionally either also add "options KDB_TRACE" and "options KDB_UNATTENDED" or set "debug.trace_on_panic=1" and "debug.debugger_on_panic=0" via sysctl(8) with a debugger-enabled kernel, the debugger will automatically print a backtrace to the console and then reboot the machine and thus minimizing downtime. Printing the backtrace might require the latest 7-STABLE though. > Meanwhile, moving over websites to another machine (another X1, > but running -current) that seems to be more stable ATM. > That's what puzzles me as every sparc64-specific change in 7-STABLE since 7.0-RELEASE also is in -current except for one stricter check in -current. So I guess you're hitting one of the MI stability issues people are reporting for 7.1-PRERELEASE. Marius