Date: Tue, 4 Jan 2005 21:58:45 -0800 From: Kris Kennaway <kris@obsecurity.org> To: David Cornejo <dave@dogwood.com> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: Fast Data Access MMU Miss problem Message-ID: <20050105055845.GA92720@xor.obsecurity.org> In-Reply-To: <6.2.0.14.2.20050104155036.04b3bd68@white.dogwood.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050105055845.GA92720>