panicstr: ffs_valloc: dup alloc with 4.9

From: Alexander Leidinger (Alexander_at_Leidinger.net)
Date: 12/02/03

  • Next message: Dr Otacon: "tcpdump will not compile with ability to decrypt ESP encapsulated packets."
    Date: Tue, 2 Dec 2003 10:51:32 +0100
    To: stable@freebsd.org
    
    

    Hi,

    I've got the following panic with a -stable as of Nov 12:
    ---snip---
    IdlePTD at phsyical address 0x003da000
    initial pcb at physical address 0x00330960
    panicstr: ffs_valloc: dup alloc
    panic messages:

    ---
    panic: ffs_valloc: dup alloc
    syncing disks... 107 15 10 10 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 
    giving up on 7 buffers
    Uptime: 6m1s
    dumping to dev #ad/0x20001, offset 1441816
    dump ata0: resetting devices .. ad0: invalidating queued requests
    done
    [dump]
    ---
    #0  dumpsys () at ../../kern/kern_shutdown.c:487
    487             if (dumping++) {
    (kgdb) bt
    #0  dumpsys () at ../../kern/kern_shutdown.c:487
    #1  0xc01967d0 in boot (howto=256) at ../../kern/kern_shutdown.c:316
    #2  0xc0196bf1 in panic (fmt=0xc02f48c1 "ffs_valloc: dup alloc")
        at ../../kern/kern_shutdown.c:595
    #3  0xc025a279 in ffs_valloc (pvp=0xd51ea300, mode=33188, cred=0xc5627280, 
        vpp=0xd5212c9c) at ../../ufs/ffs/ffs_alloc.c:620
    #4  0xc026d6c6 in ufs_makeinode (mode=33188, dvp=0xd51ea300, vpp=0xd5212ee0, 
        cnp=0xd5212ef4) at ../../ufs/ufs/ufs_vnops.c:2069
    #5  0xc026b133 in ufs_create (ap=0xd5212e00) at ../../ufs/ufs/ufs_vnops.c:195
    #6  0xc026d9c4 in ufs_vnoperate (ap=0xd5212e00)
        at ../../ufs/ufs/ufs_vnops.c:2376
    #7  0xc01cc2db in vn_open (ndp=0xd5212ecc, fmode=1538, cmode=420)
        at vnode_if.h:106
    #8  0xc01c8360 in open (p=0xd51810c0, uap=0xd5212f80)
        at ../../kern/vfs_syscalls.c:1029
    #9  0xc02aac99 in syscall2 (frame={tf_fs = 47, tf_es = -1078001617, 
          tf_ds = -719257553, tf_edi = 137940240, tf_esi = 137711504, 
          tf_ebp = -1077937596, tf_isp = -719245356, tf_ebx = 877, tf_edx = 1, 
          tf_ecx = 1537, tf_eax = 5, tf_trapno = 0, tf_err = 2, 
          tf_eip = 674122264, tf_cs = 31, tf_eflags = 646, tf_esp = -1077937640, 
          tf_ss = 47}) at ../../i386/i386/trap.c:1175
    #10 0xc029ec45 in Xint0x80_syscall ()
    #11 0x81d1f4d in ?? ()
    #12 0x5 in ?? ()
    #13 0x83083090 in ?? ()
    Cannot access memory at address 0x58a1c189.
    (kgdb) up 3
    #3  0xc025a279 in ffs_valloc (pvp=0xd51ea300, mode=33188, cred=0xc5627280, 
        vpp=0xd5212c9c) at ../../ufs/ffs/ffs_alloc.c:620
    620                     panic("ffs_valloc: dup alloc");
    (kgdb) list
    615             }
    616             ip = VTOI(*vpp);
    617             if (ip->i_mode) {
    618                     printf("mode = 0%o, inum = %lu, fs = %s\n",
    619                         ip->i_mode, (u_long)ip->i_number, fs->fs_fsmnt);
    620                     panic("ffs_valloc: dup alloc");
    621             }
    622             if (ip->i_blocks) {                             /* XXX */
    623                     printf("free inode %s/%lu had %ld blocks\n",
    624                         fs->fs_fsmnt, (u_long)ino, (long)ip->i_blocks);
    (kgdb) print *pvp
    $2 = {v_flag = 2105344, v_usecount = 2, v_writecount = 0, v_holdcnt = 2, 
      v_id = 1638, v_mount = 0xc550ce00, v_op = 0xc54b0700, v_freelist = {
        tqe_next = 0x0, tqe_prev = 0xd51ea3dc}, v_nmntvnodes = {
        tqe_next = 0xd51ea0c0, tqe_prev = 0xd51ea564}, v_cleanblkhd = {
        tqh_first = 0x0, tqh_last = 0xd51ea32c}, v_dirtyblkhd = {
        tqh_first = 0xcbc658f0, tqh_last = 0xcbc658f8}, v_synclist = {
        le_next = 0x0, le_prev = 0xc548c934}, v_numoutput = 0, v_type = VDIR, 
      v_un = {vu_mountedhere = 0x0, vu_socket = 0x0, vu_spec = {vu_specinfo = 0x0, 
          vu_specnext = {sle_next = 0x0}}, vu_fifoinfo = 0x0}, v_lease = 0x0, 
      v_lastw = 0, v_cstart = 0, v_lasta = 0, v_clen = 0, v_object = 0xd5206678, 
      v_interlock = {lock_data = 0}, v_vnlock = 0xc57c3300, v_tag = VT_UFS, 
      v_data = 0xc57c3300, v_cache_src = {lh_first = 0xc57e9000}, v_cache_dst = {
        tqh_first = 0xc57c0400, tqh_last = 0xc57c0410}, v_dd = 0xd50f6340, 
      v_ddid = 460, v_pollinfo = {vpi_lock = {lock_data = 0}, vpi_selinfo = {
          si_pid = 0, si_note = {slh_first = 0x0}, si_flags = 0}, vpi_events = 0, 
        vpi_revents = 0}, v_vxproc = 0x0}
    (kgdb) print cred
    $4 = (struct ucred *) 0x0
    (kgdb) print **vpp
    $7 = {v_flag = 0, v_usecount = 1, v_writecount = 0, v_holdcnt = 0, 
      v_id = 1955, v_mount = 0xc550ce00, v_op = 0xc54b0700, v_freelist = {
        tqe_next = 0x0, tqe_prev = 0x0}, v_nmntvnodes = {tqe_next = 0x0, 
        tqe_prev = 0xd529caa4}, v_cleanblkhd = {tqh_first = 0x0, 
        tqh_last = 0xd529c9ec}, v_dirtyblkhd = {tqh_first = 0x0, 
        tqh_last = 0xd529c9f4}, v_synclist = {le_next = 0x0, le_prev = 0x0}, 
      v_numoutput = 0, v_type = VREG, v_un = {vu_mountedhere = 0x0, 
        vu_socket = 0x0, vu_spec = {vu_specinfo = 0x0, vu_specnext = {
            sle_next = 0x0}}, vu_fifoinfo = 0x0}, v_lease = 0x0, v_lastw = 0, 
      v_cstart = 0, v_lasta = 0, v_clen = 0, v_object = 0x0, v_interlock = {
        lock_data = 0}, v_vnlock = 0xc57f6700, v_tag = VT_UFS, 
      v_data = 0xc57f6700, v_cache_src = {lh_first = 0x0}, v_cache_dst = {
        tqh_first = 0x0, tqh_last = 0xd529ca40}, v_dd = 0xd529c9c0, v_ddid = 0, 
      v_pollinfo = {vpi_lock = {lock_data = 0}, vpi_selinfo = {si_pid = 0, 
          si_note = {slh_first = 0x0}, si_flags = 0}, vpi_events = 0, 
        vpi_revents = 0}, v_vxproc = 0x0}
    ---snip---
    After this I got an unexpected softupdates inconsistency on one FS. Any
    idea why this happened? Anything I can do with the dump and gdb?
    Bye,
    Alexander.
    P.S.: I'm not subscribed to -stable.
    -- 
         The three Rs of Microsoft support: Retry, Reboot, Reinstall.
    http://www.Leidinger.net                       Alexander @ Leidinger.net
      GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
    

  • Next message: Dr Otacon: "tcpdump will not compile with ability to decrypt ESP encapsulated packets."

    Relevant Pages