Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Jan 2005 13:45:21 -1000
From:      David Cornejo <dave@dogwood.com>
To:        Kris Kennaway <kris@obsecurity.org>, Kris Kennaway <kris@obsecurity.org>
Cc:        freebsd-sparc@freebsd.org
Subject:   Re: Fast Data Access MMU Miss problem
Message-ID:  <6.2.0.14.2.20050112134405.04cfa580@white.dogwood.com>
In-Reply-To: <20050112234108.GA17895@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> <20050105055845.GA92720@xor.obsecurity.org> <20050112234108.GA17895@xor.obsecurity.org>

next in thread | previous in thread | raw e-mail | index | archive | help
If I can help out by running the patch or anything, let me know...

thanks,
dave c

At 13:41 1/12/2005, Kris Kennaway wrote:
>On Tue, Jan 04, 2005 at 09:58:45PM -0800, Kris Kennaway wrote:
> > On Tue, Jan 04, 2005 at 04:00:20PM -1000, David Cornejo wrote:
> > > You mean I have to do something besides gripe? :-)
> > >
> > > I have pasted in below the results of three crashes - the first two are
> > > pretty interesting in that they happen in _mtx_lock_sleep() when it
> > > recurses.  The third blows away the theory that it's that routine.  The
> > > common thing seems to be locking, but that could just be coincidence.
> > >
> > > I suppose I could try gdb on the kernel.  I only have one sparc 
> machine, I
> > > presume an x86 gdb won't work on this, is there anyway to get a sparc 
> gdb
> > > built under x86?  I know gdb 6 seems to be messed up when looking at the
> > > 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.
>
>FYI, bmilekic has a memory debugging patch that should help us track
>these down (in fact it's already caught one problem condition, which
>I'm waiting to hear back from him for analysis).  Stay tuned.
>
>Kris




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.2.0.14.2.20050112134405.04cfa580>