From owner-freebsd-sparc64@FreeBSD.ORG Mon Aug 15 11:01:59 2005 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF2A716A422 for ; Mon, 15 Aug 2005 11:01:59 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94FF843D45 for ; Mon, 15 Aug 2005 11:01:59 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j7FB1xvr007640 for ; Mon, 15 Aug 2005 11:01:59 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j7FB1wfd007634 for freebsd-sparc64@freebsd.org; Mon, 15 Aug 2005 11:01:58 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 15 Aug 2005 11:01:58 GMT Message-Id: <200508151101.j7FB1wfd007634@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-sparc64@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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: Mon, 15 Aug 2005 11:02:00 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/09/14] sparc64/71729sparc64 printf in kernel thread causes panic on S o [2004/10/21] sparc64/72962sparc64 [sysinstall] Sysinstall panics on sparc64 o [2004/11/02] sparc64/73413sparc64 [patch] pthread(libkse) library is broken o [2005/02/12] sparc64/77417sparc64 [panic] with high usage of cpu when lan u o [2005/04/27] sparc64/80410sparc64 netgraph is causing crash with mpd on spa o [2005/05/11] sparc64/80890sparc64 panic: kmem_malloc(73728): kmem_map too s o [2005/06/23] sparc64/82569sparc64 USB mass storage plug/unplug causes syste 7 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/10/22] sparc64/72998sparc64 [patch] set_mcontext() change syscalls pa o [2005/06/26] sparc64/82681sparc64 dc state messages 2 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Mon Aug 15 14:43:12 2005 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED33F16A41F for ; Mon, 15 Aug 2005 14:43:12 +0000 (GMT) (envelope-from john@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6919843D45 for ; Mon, 15 Aug 2005 14:43:10 +0000 (GMT) (envelope-from john@jnielsen.net) Received: from localhost (ns1 [69.55.238.237]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id j7FEh7sh047670; Mon, 15 Aug 2005 07:43:09 -0700 (PDT) (envelope-from john@jnielsen.net) From: John Nielsen To: Andrew Belashov Date: Mon, 15 Aug 2005 10:42:36 -0400 User-Agent: KMail/1.8.2 References: <200508110931.13802.john@jnielsen.net> <42FC2B2F.5060605@orel.ru> In-Reply-To: <42FC2B2F.5060605@orel.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508151042.37130.john@jnielsen.net> X-Virus-Scanned: ClamAV 0.85.1/1022/Mon Aug 15 03:03:07 2005 on ns1.jnielsen.net X-Virus-Status: Clean Cc: freebsd-sparc64@freebsd.org Subject: Re: "fast data access mmu miss" on kernels w/o "makeoptions DEBUG=-g" 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: Mon, 15 Aug 2005 14:43:13 -0000 On Friday 12 August 2005 00:53, Andrew Belashov wrote: > John Nielsen wrote: > > Can anyone say why removing "makeoptions DEBUG=-g" from a kernel would > > make it unreliable? I'm on an Ultra 5, and it's quite stable with > > either GENERIC or the kernel specified below. However, commenting out > > the "makeoptions DEBUG=-g" line builds a kernel that boots but then > > panics right after mounting /: > > > > Entropy harvesting: interrupts ethernet point_to_pointpanic: trap: fast > > data access mmu miss > > Uptime:2s > > Dumping 512 MB (2 chunks) > > Try to clean rebuild kernel (remove build directory > /usr/obj/usr/src/sys/KERNCONF or /sys/compile/KERNCONF). No change even after a fresh buildworld (using RELENG_6): cvsup /etc/supfile-src && rm -r /usr/obj/* && cd /usr/src && make make && make clean && make cleandir && make cleandir && make buildworld && make buildkernel && make installkernel && make installworld && mergemaster I don't mind leaving the option in the kernel, but it does seem like a strange bug. Let me know if anyone has any other ideas. Thanks, -John From owner-freebsd-sparc64@FreeBSD.ORG Mon Aug 15 19:25:22 2005 Return-Path: X-Original-To: sparc64@freebsd.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CFD516A41F for ; Mon, 15 Aug 2005 19:25:22 +0000 (GMT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 158E543D46 for ; Mon, 15 Aug 2005 19:25:21 +0000 (GMT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 15 Aug 2005 12:25:22 -0700 X-IronPort-AV: i="3.96,108,1122879600"; d="scan'208"; a="332373308:sNHT33327356" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7FJPCQM000299; Mon, 15 Aug 2005 12:25:13 -0700 (PDT) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [161.44.65.27]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ARJ46558; Mon, 15 Aug 2005 15:25:17 -0400 (EDT) Received: from bmcgover-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by bmcgover-pc.cisco.com (8.13.3/8.13.3) with ESMTP id j7FJPghb098353; Mon, 15 Aug 2005 15:25:46 -0400 (EDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Message-Id: <200508151925.j7FJPghb098353@bmcgover-pc.cisco.com> To: Stefan Bethke Date: Mon, 15 Aug 2005 15:25:42 -0400 From: "Brian J. McGovern" Cc: cjclark@alum.mit.edu, sparc64@freebsd.org Subject: Re: OT: Solaris Jumpstart from FreeBSD 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: Mon, 15 Aug 2005 19:25:22 -0000 I realize this email is _really_ old, but did anyone ever get jumpstarts running from FreeBSD? I'm looking at setting up a jumpstart server here, and have a number of FreeBSD boxes laying around that would be easier to use than my Solaris sytems. -Brian > > --Apple-Mail-1--227213988 > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; > charset=US-ASCII; > format=flowed > > Am 16.01.2004 um 08:20 schrieb Crist J. Clark: > > > Before I hack away at the Solaris Jumpstart tools to get them to run > > on FreeBSD, I was wondering if anyone here has done or can provide a > > pointer to someone who has already done this and is willing to share > > scripts, patches, etc. > > > > Sorry for being off topic, but I figured if any FreeBSD community knew > > of something like this, this one would. > > I always wanted to do that, but never found the time to fully set up a > server. > > One problem that I did need to solve: extract the data from a install > cd image. The standard Solaris CDs have one ISO in the usual location, > but are also labelled and have UFS filesystems on them, which are > neccessary for booting. The attached little tool will print out block > numbers from the image so that one can extract the filesystems with dd. > Sample output: > > $ ./prtdklabel Label: CD-ROM Disc for SunOS Solaris Installation > Cylinders: 2048 > Heads: 1 > Sectors: 640 > VTOC version: 1 > Partitions: 8 > Volume: > Partition #0: Tag: 0x0004, Flag: 0x0010 > Cyls: 0, 951 > Blocks: 0, 608640 > Partition #1: Tag: 0x0002, Flag: 0x0010 > Cyls: 951, 928 > Blocks: 608640, 593920 > Partition #2: Tag: 0x0000, Flag: 0x0000 > Cyls: 1879, 8 > Blocks: 1202560, 5120 > Partition #3: Tag: 0x0000, Flag: 0x0000 > Cyls: 1887, 8 > Blocks: 1207680, 5120 > Partition #4: Tag: 0x0000, Flag: 0x0000 > Cyls: 1895, 8 > Blocks: 1212800, 5120 > Partition #5: Tag: 0x0000, Flag: 0x0000 > Cyls: 1903, 8 > Blocks: 1217920, 5120 > Partition #6: Tag: 0x0000, Flag: 0x0000 > Cyls: 0, 0 > Blocks: 0, 0 > Partition #7: Tag: 0x0000, Flag: 0x0000 > Cyls: 0, 0 > Blocks: 0, 0 > > HTH, > Stefan > > > --Apple-Mail-1--227213988 > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; > x-unix-mode=0644; > name="prtdklabel.c.txt" > Content-Disposition: attachment; > filename=prtdklabel.c.txt > > /* > * Print a Sun disklabel structure > * > */ > > #include > #include > #include > > > int > compute_cksum(struct dk_label *l) > { > uint16_t *lb = (uint16_t *)l; > int i; > uint16_t cksum = 0; > > for (i=sizeof(*l)/sizeof(*lb); i; i--) { > cksum ^= *lb++; > } > return cksum; > } > > > int > main(int argc, char*argv[]) > { > struct dk_label l; > int i; > int bpc; > > read(0, &l, sizeof(l)); > > if (l.dkl_magic != DKL_MAGIC) { > printf("Invalid magic %x, not a disk label.\n", l.dkl_magic); > return 1; > } > if (compute_cksum(&l) != 0) { > printf("Correct magic, but incorrect checksum, invalid disk lab el.\n"); > return 1; > } > bpc = l.dkl_nsect*l.dkl_nhead; > printf("Label: %-.*s\n", LEN_DKL_ASCII, l.dkl_asciilabel); > printf("Cylinders: %d\n", l.dkl_ncyl); > printf("Heads: %d\n", l.dkl_nhead); > printf("Sectors: %d\n", l.dkl_nsect); > printf("VTOC version: %d\n", l.dkl_vtoc.v_version); > printf(" Partitions: %d\n", l.dkl_vtoc.v_nparts); > printf(" Volume: %-.*s\n", LEN_DKL_VVOL, l.dkl_vtoc.v_volume); > for (i=0; i printf(" Partition #%d: Tag: 0x%04x, Flag: 0x%04x\n", > i, > l.dkl_vtoc.v_part[i].p_tag, > l.dkl_vtoc.v_part[i].p_flag); > printf(" Cyls: %12d, %12d\n", l.dkl_map[i].dkl_cylno, l.dkl_map[i].dkl_nblk/bpc); > printf(" Blocks: %12d, %12d\n", l.dkl_map[i].dkl_cylno* bpc, l.dkl_map[i].dkl_nblk); > } > > return 0; > } > > --Apple-Mail-1--227213988 > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; > charset=US-ASCII; > format=flowed > > > > > -- > Stefan Bethke Fon +49 170 346 0140 > > --Apple-Mail-1--227213988 > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > freebsd-sparc64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 > To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org" > > --Apple-Mail-1--227213988-- > From owner-freebsd-sparc64@FreeBSD.ORG Wed Aug 17 21:00:12 2005 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37A9116A421 for ; Wed, 17 Aug 2005 21:00:12 +0000 (GMT) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (newtrinity.zeist.de [217.24.217.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BB8B43D53 for ; Wed, 17 Aug 2005 21:00:11 +0000 (GMT) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (localhost [127.0.0.1]) by newtrinity.zeist.de (8.12.11/8.12.11/ZEIST.DE) with ESMTP id j7HL05tM090011; Wed, 17 Aug 2005 23:00:05 +0200 (CEST) (envelope-from marius@newtrinity.zeist.de) Received: (from marius@localhost) by newtrinity.zeist.de (8.12.11/8.12.10/Submit) id j7HKxst1090004; Wed, 17 Aug 2005 22:59:54 +0200 (CEST) (envelope-from marius) Date: Wed, 17 Aug 2005 22:59:54 +0200 From: Marius Strobl To: John Nielsen Message-ID: <20050817225954.A89970@newtrinity.zeist.de> References: <200508110931.13802.john@jnielsen.net> <42FC2B2F.5060605@orel.ru> <200508151042.37130.john@jnielsen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200508151042.37130.john@jnielsen.net>; from john@jnielsen.net on Mon, Aug 15, 2005 at 10:42:36AM -0400 X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-7; AVE: 6.31.1.0; VDF: 6.31.1.126; host: newtrinity.zeist.de) Cc: freebsd-sparc64@freebsd.org Subject: Re: "fast data access mmu miss" on kernels w/o "makeoptions DEBUG=-g" 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: Wed, 17 Aug 2005 21:00:12 -0000 On Mon, Aug 15, 2005 at 10:42:36AM -0400, John Nielsen wrote: > On Friday 12 August 2005 00:53, Andrew Belashov wrote: > > John Nielsen wrote: > > > Can anyone say why removing "makeoptions DEBUG=-g" from a kernel would > > > make it unreliable? I'm on an Ultra 5, and it's quite stable with > > > either GENERIC or the kernel specified below. However, commenting out > > > the "makeoptions DEBUG=-g" line builds a kernel that boots but then > > > panics right after mounting /: > > > > > > Entropy harvesting: interrupts ethernet point_to_pointpanic: trap: fast > > > data access mmu miss > > > Uptime:2s > > > Dumping 512 MB (2 chunks) > > > > Try to clean rebuild kernel (remove build directory > > /usr/obj/usr/src/sys/KERNCONF or /sys/compile/KERNCONF). > > No change even after a fresh buildworld (using RELENG_6): > > cvsup /etc/supfile-src && rm -r /usr/obj/* && cd /usr/src && make make && > make clean && make cleandir && make cleandir && make buildworld && make > buildkernel && make installkernel && make installworld && mergemaster > > I don't mind leaving the option in the kernel, but it does seem like a > strange bug. Let me know if anyone has any other ideas. Thanks, > When the DEBUG make option is defined the compiler optimization flags (COPTFLAGS) default to '-O -pipe' whereas without DEBUG the default is '-O2 -pipe' ('-O2' can cause bogus stack traces so it's not the default for debugging kernels). So in case you also get a panic with a kernel having both: makeoptions DEBUG=-g and: makeoptions COPTFLAGS="-O2 -pipe" this probably means that there's bogus code that breaks at higher optimization levels or a compiler bug. A stack trace from such a panic might help to track this down in case it's not screwed due to the '-O2'. Marius From owner-freebsd-sparc64@FreeBSD.ORG Thu Aug 18 10:50:56 2005 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B28C16A41F for ; Thu, 18 Aug 2005 10:50:56 +0000 (GMT) (envelope-from acex5@syncer.de) Received: from titanium.webpack.hosteurope.de (titanium.webpack.hosteurope.de [217.115.142.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id 282A443D48 for ; Thu, 18 Aug 2005 10:50:55 +0000 (GMT) (envelope-from acex5@syncer.de) Received: by titanium.webpack.hosteurope.de running Exim 4.51 using esmtpsa (TLSv1:RC4-MD5:128) from dsl-084-059-232-123.arcor-ip.net ([84.59.232.123] helo=[192.168.25.150]) id 1E5hz3-0006eS-U4; Thu, 18 Aug 2005 12:50:54 +0200 Message-ID: <43046801.8000802@syncer.de> Date: Thu, 18 Aug 2005 12:50:41 +0200 From: Sebastian Koehler User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: freebsd-sparc64@freebsd.org X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: "large binaries" 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: Thu, 18 Aug 2005 10:50:56 -0000 Hi list, 1. Is it right, that all binaries on Sparc64 are completely 64Bit? Other OSes like Solaris and Linux only use a 64Bit kernel and 32Bit user space tools. 2. Why FreeBSD do it an other way? 3. Does the performance suffer from these "large binaries"? Best Regards, Sebastian From owner-freebsd-sparc64@FreeBSD.ORG Thu Aug 18 13:26:07 2005 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B198216A41F for ; Thu, 18 Aug 2005 13:26:07 +0000 (GMT) (envelope-from john@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CD5843D46 for ; Thu, 18 Aug 2005 13:26:07 +0000 (GMT) (envelope-from john@jnielsen.net) Received: from localhost (ns1 [69.55.238.237]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id j7IDPwsh092337; Thu, 18 Aug 2005 06:26:00 -0700 (PDT) (envelope-from john@jnielsen.net) From: John Nielsen To: Marius Strobl Date: Thu, 18 Aug 2005 09:24:58 -0400 User-Agent: KMail/1.8.2 References: <200508110931.13802.john@jnielsen.net> <200508151042.37130.john@jnielsen.net> <20050817225954.A89970@newtrinity.zeist.de> In-Reply-To: <20050817225954.A89970@newtrinity.zeist.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508180924.59562.john@jnielsen.net> X-Virus-Scanned: ClamAV 0.85.1/1031/Thu Aug 18 02:51:29 2005 on ns1.jnielsen.net X-Virus-Status: Clean Cc: freebsd-sparc64@freebsd.org Subject: Re: "fast data access mmu miss" on kernels w/o "makeoptions DEBUG=-g" 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: Thu, 18 Aug 2005 13:26:07 -0000 On Wednesday 17 August 2005 16:59, Marius Strobl wrote: > On Mon, Aug 15, 2005 at 10:42:36AM -0400, John Nielsen wrote: > > On Friday 12 August 2005 00:53, Andrew Belashov wrote: > > > John Nielsen wrote: > > > > Can anyone say why removing "makeoptions DEBUG=-g" from a kernel > > > > would make it unreliable? I'm on an Ultra 5, and it's quite stable > > > > with either GENERIC or the kernel specified below. However, > > > > commenting out the "makeoptions DEBUG=-g" line builds a kernel that > > > > boots but then panics right after mounting /: > > > > > > > > Entropy harvesting: interrupts ethernet point_to_pointpanic: trap: > > > > fast data access mmu miss > > > > Uptime:2s > > > > Dumping 512 MB (2 chunks) > > > > > > Try to clean rebuild kernel (remove build directory > > > /usr/obj/usr/src/sys/KERNCONF or /sys/compile/KERNCONF). > > > > No change even after a fresh buildworld (using RELENG_6): > > > > cvsup /etc/supfile-src && rm -r /usr/obj/* && cd /usr/src && make make > > && make clean && make cleandir && make cleandir && make buildworld && > > make buildkernel && make installkernel && make installworld && > > mergemaster > > > > I don't mind leaving the option in the kernel, but it does seem like a > > strange bug. Let me know if anyone has any other ideas. Thanks, > > When the DEBUG make option is defined the compiler optimization > flags (COPTFLAGS) default to '-O -pipe' whereas without DEBUG the > default is '-O2 -pipe' ('-O2' can cause bogus stack traces so it's > not the default for debugging kernels). So in case you also get a > panic with a kernel having both: > makeoptions DEBUG=-g > and: > makeoptions COPTFLAGS="-O2 -pipe" > this probably means that there's bogus code that breaks at higher > optimization levels or a compiler bug. A stack trace from such a > panic might help to track this down in case it's not screwed due > to the '-O2'. That's what it was. A kernel with only makeoptions COPTFLAGS="-O -pipe" builds and runs just fine. JN From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 19 04:33:21 2005 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85F4316A41F for ; Fri, 19 Aug 2005 04:33:21 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF67843D45 for ; Fri, 19 Aug 2005 04:33:20 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by zproxy.gmail.com with SMTP id 8so354503nzo for ; Thu, 18 Aug 2005 21:33:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=GcjWJYs8PaKMLaS7tMXfBpRhfhWqBUn6mkGjk896Ryqm+ww5+zJ5oq3LD3gX+qGk/gvcboypYjKgAwdkAJedt4JXa9XO3YZghkJp4tKGBefCzwo3FtfF27vIRsLzjmzxuTPEDetvJdlUctGs46Foe1RkfGfgOBuLWZv8/oEYrNQ= Received: by 10.36.250.79 with SMTP id x79mr2147906nzh; Thu, 18 Aug 2005 21:33:19 -0700 (PDT) Received: from michelle.rndsoft.co.kr ([211.32.202.209]) by mx.gmail.com with ESMTP id 17sm1454185nzo.2005.08.18.21.33.17; Thu, 18 Aug 2005 21:33:19 -0700 (PDT) Received: from michelle.rndsoft.co.kr (localhost.rndsoft.co.kr [127.0.0.1]) by michelle.rndsoft.co.kr (8.13.1/8.13.1) with ESMTP id j7J4UaCI011341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Aug 2005 13:30:36 +0900 (KST) (envelope-from yongari@rndsoft.co.kr) Received: (from yongari@localhost) by michelle.rndsoft.co.kr (8.13.1/8.13.1/Submit) id j7J4UQ6I011340; Fri, 19 Aug 2005 13:30:26 +0900 (KST) (envelope-from yongari@rndsoft.co.kr) Date: Fri, 19 Aug 2005 13:30:26 +0900 From: Pyun YongHyeon To: John Nielsen Message-ID: <20050819043026.GC10519@rndsoft.co.kr> References: <200508110931.13802.john@jnielsen.net> <200508151042.37130.john@jnielsen.net> <20050817225954.A89970@newtrinity.zeist.de> <200508180924.59562.john@jnielsen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200508180924.59562.john@jnielsen.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-sparc64@freebsd.org Subject: Re: "fast data access mmu miss" on kernels w/o "makeoptions DEBUG=-g" X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2005 04:33:21 -0000 On Thu, Aug 18, 2005 at 09:24:58AM -0400, John Nielsen wrote: > On Wednesday 17 August 2005 16:59, Marius Strobl wrote: > > On Mon, Aug 15, 2005 at 10:42:36AM -0400, John Nielsen wrote: > > > On Friday 12 August 2005 00:53, Andrew Belashov wrote: > > > > John Nielsen wrote: > > > > > Can anyone say why removing "makeoptions DEBUG=-g" from a kernel > > > > > would make it unreliable? I'm on an Ultra 5, and it's quite stable > > > > > with either GENERIC or the kernel specified below. However, > > > > > commenting out the "makeoptions DEBUG=-g" line builds a kernel that > > > > > boots but then panics right after mounting /: > > > > > > > > > > Entropy harvesting: interrupts ethernet point_to_pointpanic: trap: > > > > > fast data access mmu miss > > > > > Uptime:2s > > > > > Dumping 512 MB (2 chunks) > > > > > > > > Try to clean rebuild kernel (remove build directory > > > > /usr/obj/usr/src/sys/KERNCONF or /sys/compile/KERNCONF). > > > > > > No change even after a fresh buildworld (using RELENG_6): > > > > > > cvsup /etc/supfile-src && rm -r /usr/obj/* && cd /usr/src && make make > > > && make clean && make cleandir && make cleandir && make buildworld && > > > make buildkernel && make installkernel && make installworld && > > > mergemaster > > > > > > I don't mind leaving the option in the kernel, but it does seem like a > > > strange bug. Let me know if anyone has any other ideas. Thanks, > > > > When the DEBUG make option is defined the compiler optimization > > flags (COPTFLAGS) default to '-O -pipe' whereas without DEBUG the > > default is '-O2 -pipe' ('-O2' can cause bogus stack traces so it's > > not the default for debugging kernels). So in case you also get a > > panic with a kernel having both: > > makeoptions DEBUG=-g > > and: > > makeoptions COPTFLAGS="-O2 -pipe" > > this probably means that there's bogus code that breaks at higher > > optimization levels or a compiler bug. A stack trace from such a > > panic might help to track this down in case it's not screwed due > > to the '-O2'. > > That's what it was. A kernel with only > makeoptions COPTFLAGS="-O -pipe" > builds and runs just fine. > Are you sure that GENERIC kernel panics too? I couldn't verify it(I'm on a business trip) but I guess you should remove smbfs related kernel options. smbfs never worked on sparc64 and it needs more clean up on various places. If you encounter the panic again would you post stack traces? -- Regards, Pyun YongHyeon From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 19 06:17:32 2005 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA0E016A41F for ; Fri, 19 Aug 2005 06:17:32 +0000 (GMT) (envelope-from john@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 954F743D45 for ; Fri, 19 Aug 2005 06:17:30 +0000 (GMT) (envelope-from john@jnielsen.net) Received: from stealth.local (pcp09741457pcs.goosck01.sc.comcast.net [69.241.83.8]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id j7J6HLsh013968; Thu, 18 Aug 2005 23:17:24 -0700 (PDT) (envelope-from john@jnielsen.net) From: John Nielsen To: pyunyh@gmail.com Date: Fri, 19 Aug 2005 02:17:15 -0400 User-Agent: KMail/1.8.1 References: <200508110931.13802.john@jnielsen.net> <200508180924.59562.john@jnielsen.net> <20050819043026.GC10519@rndsoft.co.kr> In-Reply-To: <20050819043026.GC10519@rndsoft.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508190217.15943.john@jnielsen.net> X-Virus-Scanned: ClamAV 0.85.1/1034/Thu Aug 18 13:07:58 2005 on ns1.jnielsen.net X-Virus-Status: Clean Cc: freebsd-sparc64@freebsd.org Subject: Re: "fast data access mmu miss" on kernels w/o "makeoptions DEBUG=-g" 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: Fri, 19 Aug 2005 06:17:33 -0000 On Friday 19 August 2005 12:30 am, Pyun YongHyeon wrote: > On Thu, Aug 18, 2005 at 09:24:58AM -0400, John Nielsen wrote: > > On Wednesday 17 August 2005 16:59, Marius Strobl wrote: > > > On Mon, Aug 15, 2005 at 10:42:36AM -0400, John Nielsen wrote: > > > > On Friday 12 August 2005 00:53, Andrew Belashov wrote: > > > > > John Nielsen wrote: > > > > > > Can anyone say why removing "makeoptions DEBUG=-g" from a > > > > > > kernel would make it unreliable? I'm on an Ultra 5, and it's > > > > > > quite stable with either GENERIC or the kernel specified > > > > > > below. However, commenting out the "makeoptions DEBUG=-g" > > > > > > line builds a kernel that boots but then panics right after > > > > > > mounting /: > > > > > > > > > > > > Entropy harvesting: interrupts ethernet point_to_pointpanic: > > > > > > trap: fast data access mmu miss > > > > > > Uptime:2s > > > > > > Dumping 512 MB (2 chunks) > > > > > > > > > > Try to clean rebuild kernel (remove build directory > > > > > /usr/obj/usr/src/sys/KERNCONF or /sys/compile/KERNCONF). > > > > > > > > No change even after a fresh buildworld (using RELENG_6): > > > > > > > > cvsup /etc/supfile-src && rm -r /usr/obj/* && cd /usr/src && make > > > > make && make clean && make cleandir && make cleandir && make > > > > buildworld && make buildkernel && make installkernel && make > > > > installworld && mergemaster > > > > > > > > I don't mind leaving the option in the kernel, but it does seem > > > > like a strange bug. Let me know if anyone has any other ideas. > > > > Thanks, > > > > > > When the DEBUG make option is defined the compiler optimization > > > flags (COPTFLAGS) default to '-O -pipe' whereas without DEBUG the > > > default is '-O2 -pipe' ('-O2' can cause bogus stack traces so it's > > > not the default for debugging kernels). So in case you also get a > > > panic with a kernel having both: > > > makeoptions DEBUG=-g > > > and: > > > makeoptions COPTFLAGS="-O2 -pipe" > > > this probably means that there's bogus code that breaks at higher > > > optimization levels or a compiler bug. A stack trace from such a > > > panic might help to track this down in case it's not screwed due > > > to the '-O2'. > > > > That's what it was. A kernel with only > > makeoptions COPTFLAGS="-O -pipe" > > builds and runs just fine. > > Are you sure that GENERIC kernel panics too? > I couldn't verify it(I'm on a business trip) but I guess you should > remove smbfs related kernel options. smbfs never worked on sparc64 > and it needs more clean up on various places. > If you encounter the panic again would you post stack traces? Yes, I built about 20 kernels trying to track it down, including GENERIC sans makeoptions DEBUG=-g (but with WITNESS, etc). I haven't actually tried to use SMBFS yet, but simply having it in the kernel doesn't seem to be affecting anything. I'll see if I can get a stacktrace from an existing dump. JN From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 19 17:15:58 2005 Return-Path: X-Original-To: sparc64@FreeBSD.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D2A216A41F; Fri, 19 Aug 2005 17:15:58 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DBD043D46; Fri, 19 Aug 2005 17:15:57 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j7JHFuvf028103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Aug 2005 13:15:56 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j7JHFu6P024918; Fri, 19 Aug 2005 13:15:56 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 09E54513BD; Fri, 19 Aug 2005 13:15:55 -0400 (EDT) Date: Fri, 19 Aug 2005 13:15:55 -0400 From: Kris Kennaway To: marcel@FreeBSD.org, sparc64@FreeBSD.org Message-ID: <20050819171555.GA45748@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: kgdb still broken? 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: Fri, 19 Aug 2005 17:15:58 -0000 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline When I attempt to run kgdb on a core on sparc64 I get this: kgdb: kvm_read: invalid address (7070707) kgdb: kvm_read: invalid address (ffffd9c1) kgdb: kvm_read: invalid address (4044ac00) kgdb: kvm_read: invalid address (4044ac00) kgdb: kvm_read: invalid address (4044ac00) kgdb: kvm_read: invalid address (4044ac00) kgdb: kvm_read: invalid address (4044ac00) kgdb: kvm_read: invalid address (4044ac00) kgdb: kvm_read: invalid address (4044ac00) kgdb: kvm_read: invalid address (4044ac00) kgdb: kvm_read: invalid address (4044ac00) kgdb: kvm_read: invalid address (4044ac00) kgdb: kvm_read: invalid address (4044ac00) kgdb: kvm_read: invalid address (4044ac00) kgdb: kvm_read: invalid address (4044ac00) kgdb: kvm_read: invalid address (4044ac00) kgdb: kvm_read: invalid address (4044ac00) kgdb: kvm_read: invalid address (4044ac00) kgdb: kvm_read: invalid address (4044ac00) kgdb: kvm_read: invalid address (4044ac00) kgdb: kvm_read: invalid address (4044ac00) kgdb: kvm_read: invalid address (4044ac00) kgdb: kvm_read: invalid address (4044ac00) kgdb: kvm_read: invalid address (4044ac00) kgdb: kvm_read: invalid address (4044ac00) [...] and so on forever. Is it working for you on sparc since your recent fix? Kris --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDBhPLWry0BWjoQKURAk+BAKDB6xTCWH9ZDyeAJ64opjJIPiKnvgCgnm6o 7rdhfmz/s522TwAEYtgdZ6k= =MlP5 -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 19 23:17:14 2005 Return-Path: X-Original-To: sparc64@freebsd.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 319BC16A41F; Fri, 19 Aug 2005 23:17:14 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id B22F343D45; Fri, 19 Aug 2005 23:17:13 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j7JNHCRL042302; Fri, 19 Aug 2005 19:17:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j7JNHCW4026888; Fri, 19 Aug 2005 19:17:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 653747304D; Fri, 19 Aug 2005 19:17:12 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050819231712.653747304D@freebsd-current.sentex.ca> Date: Fri, 19 Aug 2005 19:17:12 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2005 23:17:14 -0000 TB --- 2005-08-19 22:03:19 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-08-19 22:03:19 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2005-08-19 22:03:19 - cleaning the object tree TB --- 2005-08-19 22:03:47 - checking out the source tree TB --- 2005-08-19 22:03:47 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2005-08-19 22:03:47 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-08-19 22:10:13 - building world (CFLAGS=-O2 -pipe) TB --- 2005-08-19 22:10:13 - cd /src TB --- 2005-08-19 22:10:13 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-08-19 23:13:42 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-08-19 23:13:42 - cd /src TB --- 2005-08-19 23:13:42 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Aug 19 23:13:42 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/kern/kern_exit.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/kern/kern_fork.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/kern/kern_idle.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/kern/kern_intr.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/kern/kern_jail.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/kern/kern_kse.c /src/sys/kern/kern_kse.c: In function `thread_continued': /src/sys/kern/kern_kse.c:1444: error: syntax error before string constant *** Error code 1 Stop in /obj/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-08-19 23:17:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-08-19 23:17:11 - ERROR: failed to build generic kernel TB --- 2005-08-19 23:17:11 - tinderbox aborted From owner-freebsd-sparc64@FreeBSD.ORG Sat Aug 20 00:42:35 2005 Return-Path: X-Original-To: sparc64@FreeBSD.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA4E216A41F; Sat, 20 Aug 2005 00:42:35 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A53743D46; Sat, 20 Aug 2005 00:42:35 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.4/8.13.4) with ESMTP id j7K0gY4g043958; Fri, 19 Aug 2005 17:42:34 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20050819171555.GA45748@xor.obsecurity.org> References: <20050819171555.GA45748@xor.obsecurity.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Fri, 19 Aug 2005 17:42:33 -0700 To: Kris Kennaway X-Mailer: Apple Mail (2.734) Cc: marcel@FreeBSD.org, sparc64@FreeBSD.org Subject: Re: kgdb still broken? 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: Sat, 20 Aug 2005 00:42:35 -0000 On Aug 19, 2005, at 10:15 AM, Kris Kennaway wrote: > When I attempt to run kgdb on a core on sparc64 I get this: > > kgdb: kvm_read: invalid address (7070707) > kgdb: kvm_read: invalid address (ffffd9c1) > kgdb: kvm_read: invalid address (4044ac00) *snip* > Is it working for you on sparc since your recent fix? Yes. I typically get the above (on any architecture) when the kernel is out-of-sync with the core file. Are the core file and kernel in sync? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-sparc64@FreeBSD.ORG Sat Aug 20 02:53:38 2005 Return-Path: X-Original-To: sparc64@FreeBSD.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8612716A41F; Sat, 20 Aug 2005 02:53:38 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10F9743D45; Sat, 20 Aug 2005 02:53:37 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j7K2rbvf016535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Aug 2005 22:53:37 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j7K2ra6P010283; Fri, 19 Aug 2005 22:53:36 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 2B8D151358; Fri, 19 Aug 2005 22:53:36 -0400 (EDT) Date: Fri, 19 Aug 2005 22:53:36 -0400 From: Kris Kennaway To: Marcel Moolenaar Message-ID: <20050820025336.GA94049@xor.obsecurity.org> References: <20050819171555.GA45748@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: marcel@FreeBSD.org, sparc64@FreeBSD.org, Kris Kennaway Subject: Re: kgdb still broken? 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: Sat, 20 Aug 2005 02:53:38 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 19, 2005 at 05:42:33PM -0700, Marcel Moolenaar wrote: >=20 > On Aug 19, 2005, at 10:15 AM, Kris Kennaway wrote: >=20 > >When I attempt to run kgdb on a core on sparc64 I get this: > > > >kgdb: kvm_read: invalid address (7070707) > >kgdb: kvm_read: invalid address (ffffd9c1) > >kgdb: kvm_read: invalid address (4044ac00) > *snip* >=20 > >Is it working for you on sparc since your recent fix? >=20 > Yes. I typically get the above (on any architecture) when the kernel > is out-of-sync with the core file. Are the core file and kernel in > sync? OK, that was it.. It's not making much sense of the backtrace though: (kgdb) bt #0 doadump () at /usr/src.6/sys/kern/kern_shutdown.c:233 #1 0x00000000c006a728 in db_fncall (dummy1=3D0, dummy2=3D0, dummy3=3D11, d= ummy4=3D0x16e9a41a0 "") at /usr/src.6/sys/ddb/db_command.c:486 #2 0x00000000c006a434 in db_command (last_cmdp=3D0xc040f940, cmd_table=3D0= x0, aux_cmd_tablep=3D0xc03c8dc8, aux_cmd_tablep_end=3D0xc03c8de0) at /usr/src.6/sys/ddb/db_command.c:401 #3 0x00000000c006a558 in db_command_loop () at /usr/src.6/sys/ddb/db_comma= nd.c:452 #4 0x00000000c006d0b8 in db_trap (type=3D1855603632, code=3D0) at /usr/src= .6/sys/ddb/db_main.c:221 #5 0x00000000c018d208 in kdb_trap (type=3D107, code=3D0, tf=3D0x16e9a4630)= at /usr/src.6/sys/kern/subr_kdb.c:473 #6 0x00000000c02f6b4c in trap (tf=3D0x16e9a4630) at /usr/src.6/sys/sparc64= /sparc64/trap.c:307 #7 0x00000000c0048fe0 in tl1_trap () #8 0x00000000c0048fe0 in tl1_trap () Previous frame identical to this frame (corrupt stack?) Where ddb showed that the panic correctly (see my mail to -current entitled 'panic: uma_small_alloc: free page still has mappings!'). =20 gdb53 also gets it right, but I can't examine other threads to see if they had also panicked. Kris --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDBpsvWry0BWjoQKURAo/SAJsEQM4GrT6lEfUPLu+S/ojM2AhluACcC5v1 bnsnfYcSrqxnOma8daV4+6s= =ahPC -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI-- From owner-freebsd-sparc64@FreeBSD.ORG Sat Aug 20 06:28:16 2005 Return-Path: X-Original-To: sparc64@FreeBSD.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB55116A41F; Sat, 20 Aug 2005 06:28:16 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B85243D46; Sat, 20 Aug 2005 06:28:16 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.4/8.13.4) with ESMTP id j7K6SFvS045115; Fri, 19 Aug 2005 23:28:15 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20050820025336.GA94049@xor.obsecurity.org> References: <20050819171555.GA45748@xor.obsecurity.org> <20050820025336.GA94049@xor.obsecurity.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3DBF403C-80AA-46B4-A57B-8B78F033E368@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Fri, 19 Aug 2005 23:28:14 -0700 To: Kris Kennaway X-Mailer: Apple Mail (2.734) Cc: marcel@FreeBSD.org, sparc64@FreeBSD.org Subject: Re: kgdb still broken? 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: Sat, 20 Aug 2005 06:28:17 -0000 On Aug 19, 2005, at 7:53 PM, Kris Kennaway wrote: > It's not making much sense of the backtrace though: > > (kgdb) bt > #0 doadump () at /usr/src.6/sys/kern/kern_shutdown.c:233 > #1 0x00000000c006a728 in db_fncall (dummy1=0, dummy2=0, dummy3=11, > dummy4=0x16e9a41a0 "") > at /usr/src.6/sys/ddb/db_command.c:486 > #2 0x00000000c006a434 in db_command (last_cmdp=0xc040f940, > cmd_table=0x0, aux_cmd_tablep=0xc03c8dc8, > aux_cmd_tablep_end=0xc03c8de0) at /usr/src.6/sys/ddb/ > db_command.c:401 > #3 0x00000000c006a558 in db_command_loop () at /usr/src.6/sys/ddb/ > db_command.c:452 > #4 0x00000000c006d0b8 in db_trap (type=1855603632, code=0) at /usr/ > src.6/sys/ddb/db_main.c:221 > #5 0x00000000c018d208 in kdb_trap (type=107, code=0, > tf=0x16e9a4630) at /usr/src.6/sys/kern/subr_kdb.c:473 > #6 0x00000000c02f6b4c in trap (tf=0x16e9a4630) at /usr/src.6/sys/ > sparc64/sparc64/trap.c:307 > #7 0x00000000c0048fe0 in tl1_trap () > #8 0x00000000c0048fe0 in tl1_trap () > Previous frame identical to this frame (corrupt stack?) > > Where ddb showed that the panic correctly (see my mail to -current > entitled 'panic: uma_small_alloc: free page still has mappings!'). How can you compare this backtrace with the one in the email. This backtrace is the result of a trap, not a panic. For a panic, KDB is entered via kdb_enter(), not kdb_trap() as it is in this case. It is a known issue that kgdb cannot unwind across traps right now. > gdb53 also gets it right, but I can't examine other threads to see if > they had also panicked. Do you mean that 'info threads' doesn't work or that 'thread ' doesn't work in kgdb? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-sparc64@FreeBSD.ORG Sat Aug 20 18:27:58 2005 Return-Path: X-Original-To: sparc64@FreeBSD.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1B2B16A41F; Sat, 20 Aug 2005 18:27:58 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AE8643D45; Sat, 20 Aug 2005 18:27:58 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j7KIRvvf027003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Aug 2005 14:27:57 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j7KIRu6P027582; Sat, 20 Aug 2005 14:27:56 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id E0B21513BD; Sat, 20 Aug 2005 14:27:55 -0400 (EDT) Date: Sat, 20 Aug 2005 14:27:55 -0400 From: Kris Kennaway To: Marcel Moolenaar Message-ID: <20050820182755.GA57524@xor.obsecurity.org> References: <20050819171555.GA45748@xor.obsecurity.org> <20050820025336.GA94049@xor.obsecurity.org> <3DBF403C-80AA-46B4-A57B-8B78F033E368@xcllnt.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline In-Reply-To: <3DBF403C-80AA-46B4-A57B-8B78F033E368@xcllnt.net> User-Agent: Mutt/1.4.2.1i Cc: marcel@FreeBSD.org, sparc64@FreeBSD.org, Kris Kennaway Subject: Re: kgdb still broken? 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: Sat, 20 Aug 2005 18:27:59 -0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 19, 2005 at 11:28:14PM -0700, Marcel Moolenaar wrote: > On Aug 19, 2005, at 7:53 PM, Kris Kennaway wrote: >=20 > >It's not making much sense of the backtrace though: > > > >(kgdb) bt > >#0 doadump () at /usr/src.6/sys/kern/kern_shutdown.c:233 > >#1 0x00000000c006a728 in db_fncall (dummy1=3D0, dummy2=3D0, dummy3=3D11= , =20 > >dummy4=3D0x16e9a41a0 "") > > at /usr/src.6/sys/ddb/db_command.c:486 > >#2 0x00000000c006a434 in db_command (last_cmdp=3D0xc040f940, =20 > >cmd_table=3D0x0, aux_cmd_tablep=3D0xc03c8dc8, > > aux_cmd_tablep_end=3D0xc03c8de0) at /usr/src.6/sys/ddb/=20 > >db_command.c:401 > >#3 0x00000000c006a558 in db_command_loop () at /usr/src.6/sys/ddb/=20 > >db_command.c:452 > >#4 0x00000000c006d0b8 in db_trap (type=3D1855603632, code=3D0) at /usr/= =20 > >src.6/sys/ddb/db_main.c:221 > >#5 0x00000000c018d208 in kdb_trap (type=3D107, code=3D0, =20 > >tf=3D0x16e9a4630) at /usr/src.6/sys/kern/subr_kdb.c:473 > >#6 0x00000000c02f6b4c in trap (tf=3D0x16e9a4630) at /usr/src.6/sys/=20 > >sparc64/sparc64/trap.c:307 > >#7 0x00000000c0048fe0 in tl1_trap () > >#8 0x00000000c0048fe0 in tl1_trap () > >Previous frame identical to this frame (corrupt stack?) > > > >Where ddb showed that the panic correctly (see my mail to -current > >entitled 'panic: uma_small_alloc: free page still has mappings!'). >=20 > How can you compare this backtrace with the one in the email. This > backtrace is the result of a trap, not a panic. For a panic, KDB > is entered via kdb_enter(), not kdb_trap() as it is in this case. Regardless, this is what kgdb informed me was the backtrace for the same thread that panicked and I traced with DDB and gdb53. > It is a known issue that kgdb cannot unwind across traps right now. >=20 > >gdb53 also gets it right, but I can't examine other threads to see if > >they had also panicked. >=20 > Do you mean that 'info threads' doesn't work or that 'thread ' > doesn't work in kgdb? I mean that 'info threads' doesn't work in gdb53, which is the only offline debugger one can use on sparc64 that obtains more or less reliable traces. Kris --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDB3YrWry0BWjoQKURAurHAKCoGNw7m6Ive3kwiNRXzFGRwWKq6QCgsU7F xkfRfUk7hjxQM46fAlRwU0c= =aneo -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH-- From owner-freebsd-sparc64@FreeBSD.ORG Sat Aug 20 18:55:02 2005 Return-Path: X-Original-To: freebsd-sparc64@FreeBSD.org Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F3B616A41F for ; Sat, 20 Aug 2005 18:55:02 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mail28.sea5.speakeasy.net (mail28.sea5.speakeasy.net [69.17.117.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3EB343D45 for ; Sat, 20 Aug 2005 18:55:01 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 1737 invoked from network); 20 Aug 2005 18:55:01 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender ) by mail28.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 20 Aug 2005 18:55:01 -0000 Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j7KIsrxK061016; Sat, 20 Aug 2005 14:54:53 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-sparc64@FreeBSD.org Date: Sat, 20 Aug 2005 14:53:39 -0400 User-Agent: KMail/1.8 References: <200508110931.13802.john@jnielsen.net> <20050819043026.GC10519@rndsoft.co.kr> <200508190217.15943.john@jnielsen.net> In-Reply-To: <200508190217.15943.john@jnielsen.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200508201453.40439.jhb@FreeBSD.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx Cc: John Nielsen Subject: Re: "fast data access mmu miss" on kernels w/o "makeoptions DEBUG=-g" 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: Sat, 20 Aug 2005 18:55:02 -0000 On Friday 19 August 2005 02:17 am, John Nielsen wrote: > On Friday 19 August 2005 12:30 am, Pyun YongHyeon wrote: > > On Thu, Aug 18, 2005 at 09:24:58AM -0400, John Nielsen wrote: > > > On Wednesday 17 August 2005 16:59, Marius Strobl wrote: > > > > On Mon, Aug 15, 2005 at 10:42:36AM -0400, John Nielsen wrote: > > > > > On Friday 12 August 2005 00:53, Andrew Belashov wrote: > > > > > > John Nielsen wrote: > > > > > > > Can anyone say why removing "makeoptions DEBUG=3D-g" from a > > > > > > > kernel would make it unreliable? I'm on an Ultra 5, and it's > > > > > > > quite stable with either GENERIC or the kernel specified > > > > > > > below. However, commenting out the "makeoptions DEBUG=3D-g" > > > > > > > line builds a kernel that boots but then panics right after > > > > > > > mounting /: > > > > > > > > > > > > > > Entropy harvesting: interrupts ethernet point_to_pointpanic: > > > > > > > trap: fast data access mmu miss > > > > > > > Uptime:2s > > > > > > > Dumping 512 MB (2 chunks) > > > > > > > > > > > > Try to clean rebuild kernel (remove build directory > > > > > > /usr/obj/usr/src/sys/KERNCONF or /sys/compile/KERNCONF). > > > > > > > > > > No change even after a fresh buildworld (using RELENG_6): > > > > > > > > > > cvsup /etc/supfile-src && rm -r /usr/obj/* && cd /usr/src && make > > > > > make && make clean && make cleandir && make cleandir && make > > > > > buildworld && make buildkernel && make installkernel && make > > > > > installworld && mergemaster > > > > > > > > > > I don't mind leaving the option in the kernel, but it does seem > > > > > like a strange bug. Let me know if anyone has any other ideas. > > > > > Thanks, > > > > > > > > When the DEBUG make option is defined the compiler optimization > > > > flags (COPTFLAGS) default to '-O -pipe' whereas without DEBUG the > > > > default is '-O2 -pipe' ('-O2' can cause bogus stack traces so it's > > > > not the default for debugging kernels). So in case you also get a > > > > panic with a kernel having both: > > > > makeoptions DEBUG=3D-g > > > > and: > > > > makeoptions COPTFLAGS=3D"-O2 -pipe" > > > > this probably means that there's bogus code that breaks at higher > > > > optimization levels or a compiler bug. A stack trace from such a > > > > panic might help to track this down in case it's not screwed due > > > > to the '-O2'. > > > > > > That's what it was. A kernel with only > > > makeoptions COPTFLAGS=3D"-O -pipe" > > > builds and runs just fine. > > > > Are you sure that GENERIC kernel panics too? > > I couldn't verify it(I'm on a business trip) but I guess you should > > remove smbfs related kernel options. smbfs never worked on sparc64 > > and it needs more clean up on various places. > > If you encounter the panic again would you post stack traces? > > Yes, I built about 20 kernels trying to track it down, including GENERIC > sans makeoptions DEBUG=3D-g (but with WITNESS, etc). > > I haven't actually tried to use SMBFS yet, but simply having it in the > kernel doesn't seem to be affecting anything. > > I'll see if I can get a stacktrace from an existing dump. My ultra60 won't boot a kernel that doesn't have WITNESS in it FWIW. Try a= =20 stock GENERIC kernel and see if it works. You can disable witness with the= =20 loader tunable 'debug.witness.watch=3D0'. =2D-=20 John Baldwin =A0<>< =A0http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org From owner-freebsd-sparc64@FreeBSD.ORG Sat Aug 20 18:58:57 2005 Return-Path: X-Original-To: sparc64@FreeBSD.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F233D16A41F; Sat, 20 Aug 2005 18:58:56 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8151743D45; Sat, 20 Aug 2005 18:58:56 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.4/8.13.4) with ESMTP id j7KIwuoU048783; Sat, 20 Aug 2005 11:58:56 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20050820182755.GA57524@xor.obsecurity.org> References: <20050819171555.GA45748@xor.obsecurity.org> <20050820025336.GA94049@xor.obsecurity.org> <3DBF403C-80AA-46B4-A57B-8B78F033E368@xcllnt.net> <20050820182755.GA57524@xor.obsecurity.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9D6502D2-02E7-4BAE-B3C1-AA6D4613C8BC@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sat, 20 Aug 2005 11:58:55 -0700 To: Kris Kennaway X-Mailer: Apple Mail (2.734) Cc: marcel@FreeBSD.org, sparc64@FreeBSD.org Subject: Re: kgdb still broken? 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: Sat, 20 Aug 2005 18:58:57 -0000 On Aug 20, 2005, at 11:27 AM, Kris Kennaway wrote: > On Fri, Aug 19, 2005 at 11:28:14PM -0700, Marcel Moolenaar wrote: > >> On Aug 19, 2005, at 7:53 PM, Kris Kennaway wrote: >> >> >>> It's not making much sense of the backtrace though: >>> >>> (kgdb) bt >>> #0 doadump () at /usr/src.6/sys/kern/kern_shutdown.c:233 >>> #1 0x00000000c006a728 in db_fncall (dummy1=0, dummy2=0, dummy3=11, >>> dummy4=0x16e9a41a0 "") >>> at /usr/src.6/sys/ddb/db_command.c:486 >>> #2 0x00000000c006a434 in db_command (last_cmdp=0xc040f940, >>> cmd_table=0x0, aux_cmd_tablep=0xc03c8dc8, >>> aux_cmd_tablep_end=0xc03c8de0) at /usr/src.6/sys/ddb/ >>> db_command.c:401 >>> #3 0x00000000c006a558 in db_command_loop () at /usr/src.6/sys/ddb/ >>> db_command.c:452 >>> #4 0x00000000c006d0b8 in db_trap (type=1855603632, code=0) at /usr/ >>> src.6/sys/ddb/db_main.c:221 >>> #5 0x00000000c018d208 in kdb_trap (type=107, code=0, >>> tf=0x16e9a4630) at /usr/src.6/sys/kern/subr_kdb.c:473 >>> #6 0x00000000c02f6b4c in trap (tf=0x16e9a4630) at /usr/src.6/sys/ >>> sparc64/sparc64/trap.c:307 >>> #7 0x00000000c0048fe0 in tl1_trap () >>> #8 0x00000000c0048fe0 in tl1_trap () >>> Previous frame identical to this frame (corrupt stack?) >>> >>> Where ddb showed that the panic correctly (see my mail to -current >>> entitled 'panic: uma_small_alloc: free page still has mappings!'). >>> >> >> How can you compare this backtrace with the one in the email. This >> backtrace is the result of a trap, not a panic. For a panic, KDB >> is entered via kdb_enter(), not kdb_trap() as it is in this case. >> > > Regardless, this is what kgdb informed me was the backtrace for the > same thread that panicked and I traced with DDB and gdb53. I guess I just don't understand what's you're saying then. The backtrace above clearly and reliably tells me that the core was created by calling doadump() from within DDB. Such a backtrace cannot be obtained from within DDB itself. I don't know what you get with gdb53, but it should give you the same backtrace, unless it shows the backtrace of a different thread or you were working on a different core file altogether. > I mean that 'info threads' doesn't work in gdb53, which is the only > offline debugger one can use on sparc64 that obtains more or less > reliable traces. What exactly is unreliable about backtraces in kgdb? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-sparc64@FreeBSD.ORG Sat Aug 20 19:09:59 2005 Return-Path: X-Original-To: sparc64@FreeBSD.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACA8A16A41F; Sat, 20 Aug 2005 19:09:59 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B6F743D46; Sat, 20 Aug 2005 19:09:59 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j7KJ9wvf030405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Aug 2005 15:09:58 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j7KJ9w6P029526; Sat, 20 Aug 2005 15:09:58 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id ABF0F51404; Sat, 20 Aug 2005 15:09:57 -0400 (EDT) Date: Sat, 20 Aug 2005 15:09:57 -0400 From: Kris Kennaway To: Marcel Moolenaar Message-ID: <20050820190957.GA66426@xor.obsecurity.org> References: <20050819171555.GA45748@xor.obsecurity.org> <20050820025336.GA94049@xor.obsecurity.org> <3DBF403C-80AA-46B4-A57B-8B78F033E368@xcllnt.net> <20050820182755.GA57524@xor.obsecurity.org> <9D6502D2-02E7-4BAE-B3C1-AA6D4613C8BC@xcllnt.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline In-Reply-To: <9D6502D2-02E7-4BAE-B3C1-AA6D4613C8BC@xcllnt.net> User-Agent: Mutt/1.4.2.1i Cc: marcel@FreeBSD.org, sparc64@FreeBSD.org, Kris Kennaway Subject: Re: kgdb still broken? 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: Sat, 20 Aug 2005 19:09:59 -0000 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 20, 2005 at 11:58:55AM -0700, Marcel Moolenaar wrote: > On Aug 20, 2005, at 11:27 AM, Kris Kennaway wrote: >=20 > >On Fri, Aug 19, 2005 at 11:28:14PM -0700, Marcel Moolenaar wrote: > > > >>On Aug 19, 2005, at 7:53 PM, Kris Kennaway wrote: > >> > >> > >>>It's not making much sense of the backtrace though: > >>> > >>>(kgdb) bt > >>>#0 doadump () at /usr/src.6/sys/kern/kern_shutdown.c:233 > >>>#1 0x00000000c006a728 in db_fncall (dummy1=3D0, dummy2=3D0, dummy3=3D= 11, > >>>dummy4=3D0x16e9a41a0 "") > >>> at /usr/src.6/sys/ddb/db_command.c:486 > >>>#2 0x00000000c006a434 in db_command (last_cmdp=3D0xc040f940, > >>>cmd_table=3D0x0, aux_cmd_tablep=3D0xc03c8dc8, > >>> aux_cmd_tablep_end=3D0xc03c8de0) at /usr/src.6/sys/ddb/ > >>>db_command.c:401 > >>>#3 0x00000000c006a558 in db_command_loop () at /usr/src.6/sys/ddb/ > >>>db_command.c:452 > >>>#4 0x00000000c006d0b8 in db_trap (type=3D1855603632, code=3D0) at /us= r/ > >>>src.6/sys/ddb/db_main.c:221 > >>>#5 0x00000000c018d208 in kdb_trap (type=3D107, code=3D0, > >>>tf=3D0x16e9a4630) at /usr/src.6/sys/kern/subr_kdb.c:473 > >>>#6 0x00000000c02f6b4c in trap (tf=3D0x16e9a4630) at /usr/src.6/sys/ > >>>sparc64/sparc64/trap.c:307 > >>>#7 0x00000000c0048fe0 in tl1_trap () > >>>#8 0x00000000c0048fe0 in tl1_trap () > >>>Previous frame identical to this frame (corrupt stack?) > >>> > >>>Where ddb showed that the panic correctly (see my mail to -current > >>>entitled 'panic: uma_small_alloc: free page still has mappings!'). > >>> > >> > >>How can you compare this backtrace with the one in the email. This > >>backtrace is the result of a trap, not a panic. For a panic, KDB > >>is entered via kdb_enter(), not kdb_trap() as it is in this case. > >> > > > >Regardless, this is what kgdb informed me was the backtrace for the > >same thread that panicked and I traced with DDB and gdb53. >=20 > I guess I just don't understand what's you're saying then. The > backtrace above clearly and reliably tells me that the core was > created by calling doadump() from within DDB. Such a backtrace > cannot be obtained from within DDB itself. I don't know what you > get with gdb53, but it should give you the same backtrace, unless > it shows the backtrace of a different thread or you were working > on a different core file altogether. >=20 > >I mean that 'info threads' doesn't work in gdb53, which is the only > >offline debugger one can use on sparc64 that obtains more or less > >reliable traces. >=20 > What exactly is unreliable about backtraces in kgdb? Wih gdb53 I see the following: # gdb53 -k kernel.debug vmcore.250 GNU gdb 5.3 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc64-portbld-freebsd7.0"... panic: uma_small_alloc: free page still has mappings! panic messages: --- --- #0 doadump () at /usr/src.6/sys/kern/kern_shutdown.c:233 233 savectx(&dumppcb); (kgdb) bt #0 doadump () at /usr/src.6/sys/kern/kern_shutdown.c:233 #1 0x00000000c006a720 in db_fncall (dummy1=3D0, dummy2=3D0, dummy3=3D11, d= ummy4=3D0x16e9a41a0 "") at /usr/src.6/sys/ddb/db_command.c:486 #2 0x00000000c006a42c in db_command (last_cmdp=3D0xc040f940, cmd_table=3D0= x0, aux_cmd_tablep=3D0xc03c8dc8,=20 aux_cmd_tablep_end=3D0xc03c8de0) at /usr/src.6/sys/ddb/db_command.c:401 #3 0x00000000c006a550 in db_command_loop () at /usr/src.6/sys/ddb/db_comma= nd.c:452 #4 0x00000000c006d0b0 in db_trap (type=3D1855603632, code=3D0) at /usr/src= .6/sys/ddb/db_main.c:219 #5 0x00000000c018d200 in kdb_trap (type=3D107, code=3D0, tf=3D0x16e9a4630)= at /usr/src.6/sys/kern/subr_kdb.c:473 #6 0x00000000c02f6b44 in trap (tf=3D0x16e9a4630) at /usr/src.6/sys/sparc64= /sparc64/trap.c:307 #7 0x00000000c018cddc in kdb_enter (msg=3D0x0) at /usr/src.6/sys/kern/subr= _kdb.c:267 #8 0x00000000c018cdd4 in kdb_enter (msg=3D0xc03a2650 "panic") at /usr/src.= 6/sys/kern/subr_kdb.c:267 #9 0x00000000c016e144 in panic (fmt=3D0xc03c4130 "uma_small_alloc: free pa= ge still has mappings!") at /usr/src.6/sys/kern/kern_shutdown.c:537 #10 0x00000000c02f83bc in uma_small_alloc (zone=3D0x101, bytes=3D8192, flag= s=3D0xfffff8013a465170 "=FF=FF=F8\0019=CC\020p", wait=3D3) at /usr/src.6/sys/sparc64/sparc64/vm_machdep.c:485 #11 0x00000000c02baf18 in slab_zalloc (zone=3D0xfffff8013dbfacc0, wait=3D3)= at /usr/src.6/sys/vm/uma_core.c:819 #12 0x00000000c02bc96c in uma_zone_slab (zone=3D0xfffff8013dbfacc0, flags= =3D3) at /usr/src.6/sys/vm/uma_core.c:2034 #13 0x00000000c02bcc2c in uma_zalloc_bucket (zone=3D0xfffff8013dbfacc0, fla= gs=3D3) at /usr/src.6/sys/vm/uma_core.c:2143 #14 0x00000000c02bc7d0 in uma_zalloc_arg (zone=3D0xfffff8013dbfacc0, udata= =3D0x0, flags=3D2) at /usr/src.6/sys/vm/uma_core.c:1951 #15 0x00000000c0162694 in malloc (size=3D18446735282947486976, mtp=3D0xc03f= 3368, flags=3D2) at uma.h:275 #16 0x00000000c01c5648 in allocbuf (bp=3D0xc143a920, size=3D2048) at /usr/s= rc.6/sys/kern/vfs_bio.c:2654 #17 0x00000000c01c52e8 in getblk (vp=3D0xfffff800cf995740, blkno=3D0, size= =3D2048, slpflag=3D0, slptimeo=3D0, flags=3D0) at /usr/src.6/sys/kern/vfs_bio.c:2536 #18 0x00000000c0295ad0 in ffs_balloc_ufs2 (vp=3D0xfffff800cf995740, startof= fset=3D0, size=3D512, cred=3D0xfffff8000ea86500,=20 flags=3D65536, bpp=3D0x16e9a5110) at /usr/src.6/sys/ufs/ffs/ffs_balloc.= c:676 #19 0x00000000c02b519c in ufs_mkdir (ap=3D0x16e9a5440) at /usr/src.6/sys/uf= s/ufs/ufs_vnops.c:1534 #20 0x00000000c02fa4ec in VOP_MKDIR_APV (vop=3D0xc0403a98, a=3D0x16e9a5440)= at vnode_if.c:1250 #21 0x00000000c01dd870 in kern_mkdir (td=3D0xfffff8011e0b6980, path=3D---Ca= n't read userspace from dump, or kernel process--- ) at vnode_if.h:653 #22 0x00000000c01dd570 in mkdir (td=3D0xfffff8011e0b6980, uap=3D0x16e9a58c0= ) at /usr/src.6/sys/kern/vfs_syscalls.c:3300 #23 0x00000000c02f725c in syscall (tf=3D0x16e9a5880) at /usr/src.6/sys/spar= c64/sparc64/trap.c:592 This corresponds to the ddb backtrace: db> wh Tracing pid 86114 tid 101592 td 0xfffff8011e0b6980 panic() at panic+0x164 uma_small_alloc() at uma_small_alloc+0x9c slab_zalloc() at slab_zalloc+0x98 uma_zone_slab() at uma_zone_slab+0x12c uma_zalloc_bucket() at uma_zalloc_bucket+0x16c uma_zalloc_arg() at uma_zalloc_arg+0x330 malloc() at malloc+0x114 allocbuf() at allocbuf+0x208 getblk() at getblk+0x5a8 ffs_balloc_ufs2() at ffs_balloc_ufs2+0xa30 ufs_mkdir() at ufs_mkdir+0x55c VOP_MKDIR_APV() at VOP_MKDIR_APV+0xcc kern_mkdir() at kern_mkdir+0x2f0 mkdir() at mkdir+0x10 syscall() at syscall+0x2dc -- syscall (136, FreeBSD ELF64, mkdir) %o7=3D0x105b90 -- userland() at 0x40527d08 user trace: trap %o7=3D0x105b90 pc 0x40527d08, sp 0x7fdffffd5d1 pc 0x105c6c, sp 0x7fdffffd711 done While the kgdb output is useless: (kgdb) # kgdb kernel.debug vmcore.250 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc64-marcel-freebsd". Unread portion of the kernel message buffer: =00=00=00=16=94=00=00=00=00=00=00=16=8B=00=00=00=00=00=00=00=08=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =05=AC=80=00=00=00=00=00=06=B4=80=00=00=00=00=00=00=0BY=00=00=00=00=00=00i= =00=00=00=00=00=00=00=08=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=0Bv=00=00=00=00=00=00=0E=9B=80=00=00= =00=00=00=00=16=EC=00=00=00=00=00=00=1D7=00=00=00=00=00=00=00=08=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=07=98=00=00=00=00=00=00=06=1E=80=00=00=00=00=00=00=0F0=00=00=00=00=00= =00=0C=3D=00=00=00=00=00=00=00=08=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00 =85=80=00=00=00=00=00=0C=D5=80=00=00=00=00=00=00=15=0B=00=00=00=00=00=00=19= =AB=00=00=00=00=00=00=00=08=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=07?=00=00=00=00=00=00=03q=80=00=00= =00=00=00=00=0E~=00=00=00=00=00=00=06=E3=00=00=00=00=00=00=00=08=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=06=BB=00=00=00=00=00=00=0B=84=80=00=00=00=00=00=00v=00=00=00=00=00=00= =17 =00=00=00=00=00=00=00=08=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00 #0 doadump () at /usr/src.6/sys/kern/kern_shutdown.c:233 233 savectx(&dumppcb); (kgdb) bt #0 doadump () at /usr/src.6/sys/kern/kern_shutdown.c:233 #1 0x00000000c006a728 in db_fncall (dummy1=3D0, dummy2=3D0, dummy3=3D11, d= ummy4=3D0x16e9a41a0 "") at /usr/src.6/sys/ddb/db_command.c:486 #2 0x00000000c006a434 in db_command (last_cmdp=3D0xc040f940, cmd_table=3D0= x0, aux_cmd_tablep=3D0xc03c8dc8,=20 aux_cmd_tablep_end=3D0xc03c8de0) at /usr/src.6/sys/ddb/db_command.c:401 #3 0x00000000c006a558 in db_command_loop () at /usr/src.6/sys/ddb/db_comma= nd.c:452 #4 0x00000000c006d0b8 in db_trap (type=3D1855603632, code=3D0) at /usr/src= .6/sys/ddb/db_main.c:221 #5 0x00000000c018d208 in kdb_trap (type=3D107, code=3D0, tf=3D0x16e9a4630)= at /usr/src.6/sys/kern/subr_kdb.c:473 #6 0x00000000c02f6b4c in trap (tf=3D0x16e9a4630) at /usr/src.6/sys/sparc64= /sparc64/trap.c:307 #7 0x00000000c0048fe0 in tl1_trap () #8 0x00000000c0048fe0 in tl1_trap () Previous frame identical to this frame (corrupt stack?) (kgdb) --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDB4AFWry0BWjoQKURAqqKAJ90K/xvWxh/ZGV/zRV8Zi/aSuB+OACghxqo YEE7AvnGg2VpGuMoLbi1GLU= =QX8p -----END PGP SIGNATURE----- --+QahgC5+KEYLbs62-- From owner-freebsd-sparc64@FreeBSD.ORG Sat Aug 20 19:31:04 2005 Return-Path: X-Original-To: sparc64@FreeBSD.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1ED8616A41F; Sat, 20 Aug 2005 19:31:04 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10FC243D45; Sat, 20 Aug 2005 19:31:03 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.4/8.13.4) with ESMTP id j7KJV2jb048915; Sat, 20 Aug 2005 12:31:02 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20050820190957.GA66426@xor.obsecurity.org> References: <20050819171555.GA45748@xor.obsecurity.org> <20050820025336.GA94049@xor.obsecurity.org> <3DBF403C-80AA-46B4-A57B-8B78F033E368@xcllnt.net> <20050820182755.GA57524@xor.obsecurity.org> <9D6502D2-02E7-4BAE-B3C1-AA6D4613C8BC@xcllnt.net> <20050820190957.GA66426@xor.obsecurity.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sat, 20 Aug 2005 12:31:02 -0700 To: Kris Kennaway X-Mailer: Apple Mail (2.734) Cc: marcel@FreeBSD.org, sparc64@FreeBSD.org Subject: Re: kgdb still broken? 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: Sat, 20 Aug 2005 19:31:04 -0000 On Aug 20, 2005, at 12:09 PM, Kris Kennaway wrote: >> What exactly is unreliable about backtraces in kgdb? >> > > Wih gdb53 I see the following: *snip* > #5 0x00000000c018d200 in kdb_trap (type=107, code=0, > tf=0x16e9a4630) at /usr/src.6/sys/kern/subr_kdb.c:473 > #6 0x00000000c02f6b44 in trap (tf=0x16e9a4630) at /usr/src.6/sys/ > sparc64/sparc64/trap.c:307 > #7 0x00000000c018cddc in kdb_enter (msg=0x0) at /usr/src.6/sys/ > kern/subr_kdb.c:267 > #8 0x00000000c018cdd4 in kdb_enter (msg=0xc03a2650 "panic") at / > usr/src.6/sys/kern/subr_kdb.c:267 > #9 0x00000000c016e144 in panic (fmt=0xc03c4130 "uma_small_alloc: > free page still has mappings!") > at /usr/src.6/sys/kern/kern_shutdown.c:537 *snip* > While the kgdb output is useless: *snip* > #5 0x00000000c018d208 in kdb_trap (type=107, code=0, > tf=0x16e9a4630) at /usr/src.6/sys/kern/subr_kdb.c:473 > #6 0x00000000c02f6b4c in trap (tf=0x16e9a4630) at /usr/src.6/sys/ > sparc64/sparc64/trap.c:307 > #7 0x00000000c0048fe0 in tl1_trap () > #8 0x00000000c0048fe0 in tl1_trap () > Previous frame identical to this frame (corrupt stack?) *snip* I see. As I said, kgdb cannot yet unwind across trapframes. Other than that the backtrace seems to be reliable. Not being able to unwind across backtraces is not particular to sparc64. kgdb cannot do that on any platforms. Some platforms, i386 in particular, are lucky in that kgdb is able to get out of the woods and pick up the trail after being lost for a handful of frames. This is due to the way backtraces work on those platforms. As for the resolution: I've been working on a new import of gdb, which allows us to register frame sniffers to handle this, but gdb has changed internally in such a way that our threading support cannot be compiled-in. This requires porting, which I don't want to do because it needs to be rewritten to support all platforms and merged into gdb. I don't see a point in fixing backtraces at the cost of the partial threading support we have now. In other words: it requires too much work for me to embark on it right now. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net