Hello...

I am using a LFS for the sources (cvs is much faster on a LFS). Today
I copied the data to another partition, did a "newfs_lfs -A", copied
the data back and wanted to cvs update. The kernel paniced, but I
didn't get a nice traceback. Now I tried to fsck_lfs the partition. It
did quite some things (finding several free blocks not in the free
list, later on not finding inodes, etc.). After the fsck_lfs I mounted
the partition again and, being suspicious, did a "ls -laR" on the
directories. Suddenly my kernel paniced again. 

This time I can provide all the information you might find necessary.
I have the kernel with debugging symbols handy, the kernel core dump
and got this backtrace:

(gdb) target kcore netbsd.22.core
panic: lfs_ifind: dinode %u not found
#0  0x1 in ?? ()
(gdb) bt
#0  0x1 in ?? ()
#1  0xc025b1bf in cpu_reboot (howto=256, bootstr=0x0)
    at /usr/src/sys/arch/i386/i386/machdep.c:2165
#2  0xc012472f in db_sync_cmd ()
    at /usr/cvs.netbsd/src/sys/ddb/db_command.c:748
#3  0xc0124280 in db_command (last_cmdp=0xc0329258,
cmd_table=0xc02c6ce0)
    at /usr/cvs.netbsd/src/sys/ddb/db_command.c:324
#4  0xc0124497 in db_command_loop ()
    at /usr/cvs.netbsd/src/sys/ddb/db_command.c:583
#5  0xc0127a0c in db_trap (type=1, code=0)
    at /usr/cvs.netbsd/src/sys/ddb/db_trap.c:92
#6  0xc025812a in kdb_trap (type=1, code=0, regs=0xcb403bd0)
    at /usr/cvs.netbsd/src/sys/arch/i386/i386/db_interface.c:129
#7  0xc0261aaf in trap (frame={tf_gs = 16, tf_fs = 16, tf_es =
-884998128,
      tf_ds = -884998128, tf_edi = 256, tf_esi = -1070673184,
      tf_ebp = -884982768, tf_ebx = -884982724, tf_edx = -1070794918,
      tf_ecx = 24, tf_eax = 6534, tf_trapno = 1, tf_err = 0,
      tf_eip = -1071283728, tf_cs = 8, tf_eflags = 514, tf_esp =
-884982736,
      tf_ss = -1072369115, tf_vm86_es = -1066139648, tf_vm86_ds =
-1016389592,
      tf_vm86_fs = 146762, tf_vm86_gs = -1072367725})
    at /usr/src/sys/arch/i386/i386/trap.c:218
#8  0xc0100c35 in calltrap ()
#9  0xc014f225 in panic (fmt=0xc02ed2e0 "lfs_ifind: dinode %u not
found")
    at /usr/cvs.netbsd/src/sys/kern/subr_prf.c:237
---Type <return> to continue, or q <return> to quit---
#10 0xc02311a3 in lfs_ifind (fs=0xc0740000, ino=146762, bp=0xc36b2028)
    at /usr/src/sys/ufs/lfs/lfs_inode.c:140
#11 0xc023b4c0 in lfs_vget (mp=0xc0711000, ino=146762, vpp=0xcb403d4c)
    at /usr/src/sys/ufs/lfs/lfs_vfsops.c:1399
#12 0xc023ff65 in ufs_lookup (v=0xcb403dd0)
    at /usr/src/sys/ufs/ufs/ufs_lookup.c:592
#13 0xc0168721 in lookup (ndp=0xcb403e98)
    at /usr/cvs.netbsd/src/sys/sys/vnode_if.h:87
#14 0xc0168385 in namei (ndp=0xcb403e98)
    at /usr/cvs.netbsd/src/sys/kern/vfs_lookup.c:159
#15 0xc016f153 in sys___lstat13 (p=0xcb32dca4, v=0xcb403f80,
retval=0xcb403f78)
    at /usr/cvs.netbsd/src/sys/kern/vfs_syscalls.c:1985
#16 0xc0261687 in syscall_plain (frame={tf_gs = 31, tf_fs = -65505,
      tf_es = 31, tf_ds = -1078001633, tf_edi = 134996480, tf_esi =
134957680,
      tf_ebp = -1077946616, tf_ebx = 134996560, tf_edx = -1077946712,
      tf_ecx = 0, tf_eax = 280, tf_trapno = 3, tf_err = 2, tf_eip =
134678431,
      tf_cs = 23, tf_eflags = 647, tf_esp = -1077946756, tf_ss = 31,
      tf_vm86_es = 0, tf_vm86_ds = 0, tf_vm86_fs = 0, tf_vm86_gs = 0})
    at /usr/src/sys/arch/i386/i386/syscall.c:140
#17 0xc0100cf6 in syscall1 ()
can not access 0xbfbfd708, invalid translation (invalid PDE)
can not access 0xbfbfd708, invalid translation (invalid PDE)
Cannot access memory at address 0xbfbfd708


The version is:

NetBSD hermit.home.cs.tu-berlin.de 1.5ZA NetBSD 1.5ZA (LABITZKE) #775: Sun Jan 13 20:33:11 CET 2002     hermit@hermit.home.cs.tu-berlin.de:/usr/local/junk/build1/kernels/LABITZKE i386

This is built from -current cvs updated from cvs.netbsd.org a few
hours before the given date above. The user land is in sync with that.

Is this problem known?

I am just sending this to -current-users, because I don't have the
time to follow it up further at the moment. In two weeks I will update
my sources again and rebuild, but now this is no option for me. If a
developer needs the kernel and/or crash dump, I can provide them.

Many thanks in advance,
Björn

-- 
Bjoern Labitzke  <hermit@cs.tu-berlin.de>
   Use GPG! (Don't you use envelopes for your letters?)