Subject: kern/17093: crash in NFSland
To: None <gnats-bugs@gnats.netbsd.org>
From: None <dogcow@redback.com>
List: netbsd-bugs
Date: 05/28/2002 16:56:01
>Number: 17093
>Category: kern
>Synopsis: crash in NFSland
>Confidential: no
>Severity: serious
>Priority: low
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue May 28 16:57:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:
>Release: NetBSD 1.5.3
>Organization:
Redback Networks
>Environment:
System: NetBSD therock 1.5.3 NetBSD 1.5.3 (NETEGON) #12: Fri Apr 5 19:04:28 PST 2002 notroot@egon.redback.com:/netbsd15/nbsrc153/sys/arch/i386/compile/NETEGON i386
>Description:
Once in a while we get weirdo crashes; I don't know if this problem is
exacerbated by netbooting, but they usually panic with "trap" and in the
middle of doing some NFS inode parsing.
backtrace:
(gdb) target kcore netbsd.0.core
panic: trap
#0 0x100 in ?? ()
#1 0xc01fec57 in cpu_reboot (howto=256, bootstr=0x0)
at ../../../../arch/i386/i386/machdep.c:1175
#2 0xc0154295 in panic () at ../../../../kern/subr_prf.c:240
#3 0xc020610d in trap (frame={tf_gs = 0, tf_fs = -1065418752,
tf_es = -1065418736, tf_ds = -1065418736, tf_edi = -746259208,
tf_esi = -746259200, tf_ebp = -746259264, tf_ebx = -746259196,
tf_edx = -1064419936, tf_ecx = -746259028, tf_eax = 0, tf_trapno = 6,
tf_err = 0, tf_eip = -1071889777, tf_cs = 8, tf_eflags = 66194,
tf_esp = 0, tf_ss = -746259200, tf_vm86_es = -746259196,
tf_vm86_ds = -1065403392, tf_vm86_fs = -746259184,
tf_vm86_gs = -1071863620}) at ../../../../arch/i386/i386/trap.c:310
#4 0xc0100d2d in calltrap ()
#5 0xc01ca8bc in nfs_getattr (v=0xd384fdac) at ../../../../nfs/nfs_vnops.c:599
#6 0xc01cc5f9 in nfs_lookup (v=0xd384fe60) at ../../../../sys/vnode_if.h:221
#7 0xc016b8cb in lookup (ndp=0xd384fef0) at ../../../../sys/vnode_if.h:71
#8 0xc016b5bf in namei (ndp=0xd384fef0) at ../../../../kern/vfs_lookup.c:153
#9 0xc01720bd in sys_chown (p=0xd371acb0, v=0xd384ff80, retval=0xd384ff78)
at ../../../../kern/vfs_syscalls.c:2302
#10 0xc020670c in syscall (frame={tf_gs = 43, tf_fs = 43, tf_es = 43,
tf_ds = 43, tf_edi = 0, tf_esi = 0, tf_ebp = -1077946536,
tf_ebx = 134881728, tf_edx = 0, tf_ecx = 0, tf_eax = 16, tf_trapno = 3,
tf_err = 2, tf_eip = 1210770359, tf_cs = 35, tf_eflags = 646,
tf_esp = -1077946564, tf_ss = 43, tf_vm86_es = 0, tf_vm86_ds = 0,
tf_vm86_fs = 0, tf_vm86_gs = 0}) at ../../../../arch/i386/i386/trap.c:801
#11 0xc0100de5 in syscall1 ()
can not access 0xbfbfd758, invalid translation (invalid PDE)
can not access 0xbfbfd758, invalid translation (invalid PDE)
Cannot access memory at address 0xbfbfd758.
(gdb) up
#5 0xc01ca8bc in nfs_getattr (v=0xd384fdac) at ../../../../nfs/nfs_vnops.c:599
599 nfsm_loadattr(vp, ap->a_vap);
$3 = {v_uvm = {u_obj = {vmobjlock = {lock_data = 0}, pgops = 0x0, memq = {
tqh_first = 0x0, tqh_last = 0x0}, uo_npages = 0, uo_refs = 0},
u_flags = 0, u_nio = 0, u_size = 0, u_wlist = {le_next = 0x0,
le_prev = 0x0}, u_syncq = {sqe_next = 0x0}}, v_flag = 8, v_usecount = 1,
v_writecount = 0, v_holdcnt = 0, v_lastr = 0, v_id = 18144, v_mount = 0x0,
v_op = 0xc07be600, v_freelist = {tqe_next = 0x0, tqe_prev = 0xd35c9634},
v_mntvnodes = {le_next = 0xd3529ebc, le_prev = 0xd352f14c}, v_cleanblkhd = {
lh_first = 0x0}, v_dirtyblkhd = {lh_first = 0x0}, v_numoutput = 0,
v_synclist = {le_next = 0x0, le_prev = 0x0}, v_type = VBAD, v_un = {
vu_mountedhere = 0x0, vu_socket = 0x0, vu_vmdata = 0x0, vu_specinfo = 0x0,
vu_fifoinfo = 0x0}, v_lease = 0x0, v_lastw = 0, v_cstart = 0, v_lasta = 0,
v_clen = 0, v_ralen = 0, v_maxra = 0, v_interlock = {lock_data = 0},
v_lock = {lk_interlock = {lock_data = 0}, lk_flags = 0, lk_sharecount = 0,
lk_exclusivecount = 0, lk_recurselevel = 0, lk_waitcount = 0,
lk_wmesg = 0xc0290625 "vnlock", lk_un = {lk_un_sleep = {
lk_sleep_lockholder = -1, lk_sleep_prio = 20, lk_sleep_timo = 0},
lk_un_spin = {lk_spin_cpu = 4294967295}}}, v_vnlock = 0x0,
v_tag = VT_NON, v_data = 0x0}
I don't know what the heck most of the vars mean, but it seems like there
are far too many zeroes in that list.
I can provide the snapshot of the source, the kernel with gdb symbols,
and the crash dump if need be.
>How-To-Repeat:
There doesn't seem to be much of a pattern, alas.
>Fix:
Unknown.
>Release-Note:
>Audit-Trail:
>Unformatted: