From owner-freebsd-sparc64@FreeBSD.ORG Wed Jan 5 05:58:22 2005 Return-Path: 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 AF15C16A4CE for ; Wed, 5 Jan 2005 05:58:22 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60C4943D39 for ; Wed, 5 Jan 2005 05:58:22 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id E381F51814; Tue, 4 Jan 2005 21:58:45 -0800 (PST) Date: Tue, 4 Jan 2005 21:58:45 -0800 From: Kris Kennaway To: David Cornejo Message-ID: <20050105055845.GA92720@xor.obsecurity.org> References: <20050103104025.A6665@carver.gumbysoft.com> <20050104014112.23160.qmail@web17309.mail.tpe.yahoo.com> <6.2.0.14.2.20050104102555.049faa18@white.dogwood.com> <20050104222258.GB79661@xor.obsecurity.org> <6.2.0.14.2.20050104155036.04b3bd68@white.dogwood.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline In-Reply-To: <6.2.0.14.2.20050104155036.04b3bd68@white.dogwood.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-sparc@freebsd.org cc: Kris Kennaway Subject: Re: Fast Data Access MMU Miss problem X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2005 05:58:22 -0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 04, 2005 at 04:00:20PM -1000, David Cornejo wrote: > You mean I have to do something besides gripe? :-) >=20 > I have pasted in below the results of three crashes - the first two are= =20 > pretty interesting in that they happen in _mtx_lock_sleep() when it=20 > recurses. The third blows away the theory that it's that routine. The= =20 > common thing seems to be locking, but that could just be coincidence. >=20 > I suppose I could try gdb on the kernel. I only have one sparc machine, = I=20 > presume an x86 gdb won't work on this, is there anyway to get a sparc gdb= =20 > built under x86? I know gdb 6 seems to be messed up when looking at the= =20 > crash dumps, should I try 5.3 on the live kernel also? I've not had luck using anything other than the gdb53 port which you're using, but this is fine. Actually, looking at your traces I've seen the first two myself - there seems to be a problem with file descriptor reference counting in RELENG_5 and HEAD, and some other memory use-after-free bugs that I've not had any luck getting tracked down so far. > #6 0x00000000c0104ae8 in fdfree (td=3D0xfffff800a7667560) > at ../../../kern/kern_descrip.c:1610 > #7 0x00000000c010f2f8 in exit1 (td=3D0xfffff800a7667560, rv=3D0) > at ../../../kern/kern_exit.c:230 > #8 0x00000000c0110470 in sys_exit (td=3D0xfffff800a7667560, uap=3D0xe9ec= b8c0) > at ../../../kern/kern_exit.c:93 > #9 0x00000000c02aad4c in syscall (tf=3D0xe9ecb880) > at ../../../sparc64/sparc64/trap.c:592 I've also seen this one: > #6 0x00000000c0192cc8 in namei (ndp=3D0xed1435a0) > at ../../../kern/vfs_lookup.c:161 > #7 0x00000000c01a18cc in stat (td=3D0xfffff8003b0ef7c0, uap=3D0xed1438c0) > at namei.h:157 > #8 0x00000000c02aad4c in syscall (tf=3D0xed143880) > at ../../../sparc64/sparc64/trap.c:592 > (kgdb) although not this one (which might be related to #2, though). > #3 0x00000000c02aa87c in trap (tf=3D0xed7db050) at=20 > ../../../sparc64/sparc64/trap.c:369 > #4 0x00000000c01991d8 in vref (vp=3D0x0) at atomic.h:278 > #5 0x00000000c0158aa4 in turnstile_lock (lock=3D0x0) at=20 > ../../../kern/subr_turnstile.c:458 > #6 0x00000000c019291c in namei (ndp=3D0xed7db620) at=20 > ../../../kern/vfs_lookup.c:165 > #7 0x00000000c010e068 in kern_execve (td=3D0xfffff8008057e4c0,=20 > fname=3D---Can't read userspace from dump, or kernel process--- I'll let you know if I find a fix to these. Kris --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB24IVWry0BWjoQKURAjxGAKDkFHjLpC0ZlWmE43zOaM3Yxv450QCg2c2j +ayr3/rTPuyDr9rtjidfN3U= =I8uF -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH--