Fast Data Access MMU Miss problem

Kris Kennaway kris at obsecurity.org
Tue Jan 4 21:58:22 PST 2005


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.

> #6  0x00000000c0104ae8 in fdfree (td=0xfffff800a7667560)
>     at ../../../kern/kern_descrip.c:1610
> #7  0x00000000c010f2f8 in exit1 (td=0xfffff800a7667560, rv=0)
>     at ../../../kern/kern_exit.c:230
> #8  0x00000000c0110470 in sys_exit (td=0xfffff800a7667560, uap=0xe9ecb8c0)
>     at ../../../kern/kern_exit.c:93
> #9  0x00000000c02aad4c in syscall (tf=0xe9ecb880)
>     at ../../../sparc64/sparc64/trap.c:592

I've also seen this one:

> #6  0x00000000c0192cc8 in namei (ndp=0xed1435a0)
>     at ../../../kern/vfs_lookup.c:161
> #7  0x00000000c01a18cc in stat (td=0xfffff8003b0ef7c0, uap=0xed1438c0)
>     at namei.h:157
> #8  0x00000000c02aad4c in syscall (tf=0xed143880)
>     at ../../../sparc64/sparc64/trap.c:592
> (kgdb)

although not this one (which might be related to #2, though).

> #3  0x00000000c02aa87c in trap (tf=0xed7db050) at 
> ../../../sparc64/sparc64/trap.c:369
> #4  0x00000000c01991d8 in vref (vp=0x0) at atomic.h:278
> #5  0x00000000c0158aa4 in turnstile_lock (lock=0x0) at 
> ../../../kern/subr_turnstile.c:458
> #6  0x00000000c019291c in namei (ndp=0xed7db620) at 
> ../../../kern/vfs_lookup.c:165
> #7  0x00000000c010e068 in kern_execve (td=0xfffff8008057e4c0, 
> fname=---Can't read userspace from dump, or kernel process---

I'll let you know if I find a fix to these.

Kris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20050104/f2bcb635/attachment.bin


More information about the freebsd-sparc64 mailing list