On 19 Aug, Alex Zepeda wrote:
> ../../../kern/kern_synch.c:454: sleeping with "mntvnode" locked from
>../../../kern/vfs_subr.c:2789
> panic: from debugger
> cpuid = 0; lapic.id = 00000000
> -------
>
> GNU gdb 5.2.0 (FreeBSD) 20020627
> This GDB was configured as "i386-undermydesk-freebsd"...
> #10 0xc02218d3 in panic () at ../../../kern/kern_shutdown.c:493
> #11 0xc016d1ed in db_panic () at ../../../ddb/db_command.c:449
> #12 0xc016d18c in db_command (last_cmdp=0xc03c4440, cmd_table=0x0,
> aux_cmd_tablep=0xc03bb4f0, aux_cmd_tablep_end=0xc03bb4f4)
> at ../../../ddb/db_command.c:345
> #13 0xc016d25b in db_command_loop () at ../../../ddb/db_command.c:471
> #14 0xc016f692 in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
> #15 0xc03257a8 in kdb_trap (type=3, code=0, regs=0xc9c17a28)
> at ../../../i386/i386/db_interface.c:161
> #16 0xc0339fcc in trap (frame=
> {tf_fs = -1071448040, tf_es = -1070006256, tf_ds = 16, tf_edi = 1, tf_esi = 0,
>tf_ebp = -910067092, tf_isp = -910067116, tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax
>= 26, tf_trapno = 3, tf_err = 0, tf_eip = -1070441902, tf_cs = 8, tf_eflags = 642,
>tf_esp = -1, tf_ss = -910067060}) at ../../../i386/i386/trap.c:605
> #17 0xc0326bc8 in calltrap () at /var/tmp//ccTCRbXy.s:99
> #18 0xc023bb23 in witness_sleep (check_only=0, lock=0xc042bbe0,
> file=0xc038d8ee "../../../kern/kern_synch.c", line=454)
> at ../../../kern/subr_witness.c:927
> #19 0xc022653c in msleep (ident=0xc223a7b8, mtx=0xc042bbe0, priority=72,
> wmesg=0x0, timo=0) at ../../../kern/kern_synch.c:454
> #20 0xc0217497 in acquire (lkp=0xc223a7b8, extflags=16777280, wanted=1536)
> at ../../../kern/kern_lock.c:168
> #21 0xc02177d0 in lockmgr (lkp=0xc223a7b8, flags=16842754, interlkp=0x1000040,
> td=0xc2667480) at ../../../kern/kern_lock.c:381
> #22 0xc025c758 in vop_stdlock (ap=0x0) at ../../../kern/vfs_default.c:279
> #23 0xc02ee573 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2770
> #24 0xc026c36a in vn_lock (vp=0xc223a6f0, flags=65538, td=0xc2667480)
> at vnode_if.h:871
> #25 0xc0263665 in vrele (vp=0xc223a6f0) at ../../../kern/vfs_subr.c:1963
> #26 0xc0264a5a in sysctl_vnode (oidp=0xc03f9aa0, arg1=0x0, arg2=0,
> req=0xc9c17c08) at ../../../kern/vfs_subr.c:2835
> #27 0xc0228826 in sysctl_root (oidp=0x0, arg1=0xc9c17cb4, arg2=2,
> req=0xc9c17c08) at ../../../kern/kern_sysctl.c:1147
> #28 0xc02289e4 in userland_sysctl (td=0x0, name=0xc9c17cb4, namelen=2,
> old=0xc9c17c60, oldlenp=0xa, inkernel=0, new=0xc9c17c30, newlen=0,
> retval=0xc9c17cb0) at ../../../kern/kern_sysctl.c:1242
> #29 0xc02288a9 in __sysctl (td=0xc2667480, uap=0xc9c17d14)
> at ../../../kern/kern_sysctl.c:1181
> #30 0xc033a7a4 in syscall (frame=
> {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077939888, tf_esi = 2, tf_ebp
>= -1079200088, tf_isp = -910066316, tf_ebx = -1079200048, tf_edx = -1077937728,
>tf_ecx = -1077939912, tf_eax = 202, tf_trapno = 12, tf_err = 2, tf_eip = 134575943,
>tf_cs = 31, tf_eflags = 658, tf_esp = -1079200132, tf_ss = 47})
> at ../../../i386/i386/trap.c:1050
> #31 0xc0326c1d in Xint0x80_syscall () at /var/tmp//ccTCRbXy.s:141
> ---Can't read userspace from dump, or kernel process--->
> (kgdb) quit
>
> Anything I can do here to help?
This is getting triggered by the kern.vnode sysctl. SMP or UP? Offhand
I have a hard time seeing how the sequence
vref(vp)
do cpu bound stuff
vrele(vp)
would do anything other than increment and decrement the vnode reference
count on a UP box. Even on an SMP box, what are the chances that some
other process would vrele() a vnode while the sysctl handler had a
reference to it and was copying some data from it?
Does "sysctl kern.vnode" trigger this panic while the machine is idle?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
