On Wed, Apr 27, 2005 at 02:11:14PM -0700, Kris Kennaway wrote: > Actually, my last message was not from the e4500 but another SMP > sparc64 running 6.0. Here's the panic from the e4500 overnight. > Unfortunately no ktr is available but I have a dump. > > panic: trap: fast data access mmu miss > cpuid = 10 > KDB: enter: panic > [thread pid 64968 tid 100313 ] > Stopped at kdb_enter+0x3c: ta %xcc, 1 > db> wh > Tracing pid 64968 tid 100313 td 0xfffff800e70f3c80 > panic() at panic+0x16c > trap() at trap+0x3f0 > -- fast data access mmu miss tar=0 %o7=0xc0162240 -- > ufs_remove() at ufs_remove+0xc > VOP_REMOVE_APV() at VOP_REMOVE_APV+0xb4 > kern_unlink() at kern_unlink+0x174 > unlink() at unlink+0xc > syscall() at syscall+0x2b4 > -- syscall (10, FreeBSD ELF64, unlink) %o7=0x101998 -- #9 0x00000000c016bc0c in panic (fmt=0xc03bc778 "trap: %s") at /usr/src.6/sys/kern/kern_shutdown.c:537 #10 0x00000000c02f1450 in trap (tf=0xf7b9b1c0) at /usr/src.6/sys/sparc64/sparc64/trap.c:369 #11 0x00000000c02b070c in ufs_remove (ap=0xfffff800220a6c78) at /usr/src.6/sys/ufs/ufs/ufs_vnops.c:757 #12 0x00000000c0162240 in _mtx_unlock_flags (m=0xf7b9b500, opts=-1069915136, file=0xc03a7030 "/usr/src.6/sys/kern/vfs_vnops.c", line=919) at /usr/src.6/sys/kern/kern_mutex.c:299 #13 0x00000000c02f3fb4 in VOP_REMOVE_APV (vop=0xc03fcf40, a=0xf7b9b500) at vnode_if.c:1074 #14 0x00000000c01d9c54 in kern_unlink (td=0xfffff800e70f3c80, path=---Can't read userspace from dump, or kernel process--- ) at vnode_if.h:563 #15 0x00000000c01d9acc in unlink (td=0xfffff800e70f3c80, uap=0xf7b9b8c0) at /usr/src.6/sys/kern/vfs_syscalls.c:1622 (kgdb) frame 11 #11 0x00000000c02b070c in ufs_remove (ap=0xfffff800220a6c78) at /usr/src.6/sys/ufs/ufs/ufs_vnops.c:757 757 ip = VTOI(vp); (kgdb) print *vp $2 = {v_type = 4294965248, v_tag = 0xfffff8013e7490a0 "[binary data deleted - KK]", v_op = 0x0, v_data = 0x0, v_mount = 0xf7b9b980, v_nmntvnodes = {tqe_next = 0x61ef, tqe_prev = 0x54450ffc704ddc62}, v_un = { vu_mount = 0x17e9f910000000a, vu_socket = 0x17e9f910000000a, vu_cdev = 0x17e9f910000000a, vu_fifoinfo = 0x17e9f910000000a}, v_hashlist = {le_next = 0x40000000bff, le_prev = 0xea5cda90}, v_hash = 0, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0x0}, v_dd = 0x0, v_cstart = 3931962088, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lk_interlock = 0xea5cfb08, lk_flags = 0, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 0, lk_prio = 0, lk_wmesg = 0x0, lk_timo = 0, lk_lockholder = 0x0, lk_newlock = 0x0}, v_interlock = {mtx_object = {lo_class = 0x0, lo_name = 0xea5cfb48 "", lo_type = 0x0, lo_flags = 0, lo_list = {tqe_next = 0x0, tqe_prev = 0xea5cfb68}, lo_witness = 0x0}, mtx_lock = 0, mtx_recurse = 0, mtx_acqtime = 3931962248, mtx_filename = 0x0, mtx_lineno = 0, mtx_contest_holding = 0, mtx_contest_locking = 0}, v_vnlock = 0xea5cfba8, v_holdcnt = 0, v_usecount = 0, v_vxthread = 0x0, v_iflag = 0, v_vflag = 3931962312, v_writecount = 0, v_freelist = { tqe_next = 0x0, tqe_prev = 0x0}, v_bufobj = {bo_mtx = 0xea5cfbe8, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0x0}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0x0}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0x0, bo_bsize = 0, bo_object = 0x0, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0xea5cfc68, __bo_vnode = 0x0}, v_pollinfo = 0x0, v_label = 0x0} (kgdb) frame 12 #12 0x00000000c0162240 in _mtx_unlock_flags (m=0xf7b9b500, opts=-1069915136, file=0xc03a7030 "/usr/src.6/sys/kern/vfs_vnops.c", line=919) at /usr/src.6/sys/kern/kern_mutex.c:299 299 mtx_assert(m, MA_OWNED); (kgdb) frame 13 #13 0x00000000c02f3fb4 in VOP_REMOVE_APV (vop=0xc03fcf40, a=0xf7b9b500) at vnode_if.c:1074 1074 if (vop->vop_remove != NULL) (kgdb) frame 14 #14 0x00000000c01d9c54 in kern_unlink (td=0xfffff800e70f3c80, path=---Can't read userspace from dump, or kernel process--- ) at vnode_if.h:563 563 vnode_if.h: No such file or directory. in vnode_if.h (kgdb)
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:33 UTC