Re: panic in ufs_remove() on 6.0

From: Kris Kennaway <kris_at_obsecurity.org>
Date: Wed, 27 Apr 2005 17:09:04 -0700
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)
Received on Wed Apr 27 2005 - 22:09:08 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:33 UTC