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: