>Number:         9319
>Category:       kern
>Synopsis:       panic: lfs_ialloc: inuse inode 35888 on the free list
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jan 30 15:06:01 2000
>Last-Modified:
>Originator:     Manuel Bouyer
>Organization:

None

>Release:        1.4Q as of yesterday
>Environment:

System: NetBSD rochebonne.antioche.eu.org 1.4Q NetBSD 1.4Q (ROCHEBONNE) #2: Fri Jan 28 00:28:39 MET 2000 bouyer@rochebonne.antioche.eu.org:/usr/src/1.4Q/src/sys/arch/i386/compile/ROCHEBONNE i386

>Description:
	
	I have a LFS /usr/src. From a frech source tree expanded on a just-
	newfs'd LFS,
	'cd /usr/src/1.4Q/src/sys/arch/i386/compile/ROCHEBONNE && make &&
	rm *.o && make' will reliably trigger the above panic. The inode
	number may change.
	Stack trace:
#9  0xf014198d in panic (
    fmt=0xf024d600 "lfs_ialloc: inuse inode %d on the free list")
    at ../../../../kern/subr_prf.c:214
---Type <return> to continue, or q <return> to quit---
#10 0xf01dbc5e in lfs_valloc (v=0xfe0ebca0)
    at ../../../../ufs/lfs/lfs_alloc.c:149
#11 0xf01ea14e in ufs_makeinode (mode=33188, dvp=0xfe01e82c, vpp=0xfe0ebee8, 
    cnp=0xfe0ebefc) at ../../../../sys/vnode_if.h:933
#12 0xf01e7542 in ufs_create (v=0xfe0ebe08)
    at ../../../../ufs/ufs/ufs_vnops.c:118
#13 0xf01e4006 in lfs_create (v=0xfe0ebe08)
    at ../../../../ufs/lfs/lfs_vnops.c:451
#14 0xf01605d8 in vn_open (ndp=0xfe0ebed8, fmode=1538, cmode=420)
    at ../../../../sys/vnode_if.h:96
#15 0xf015cb50 in sys_open (p=0xfe0a3dc8, v=0xfe0ebf88, retval=0xfe0ebf80)
    at ../../../../kern/vfs_syscalls.c:999
#16 0xf0203746 in syscall (frame={tf_es = 31, tf_ds = -272695265, 
      tf_edi = -272637968, tf_esi = 1209353536, tf_ebp = -272639432, 
      tf_ebx = 1209310128, tf_edx = 16, tf_ecx = 1208796712, tf_eax = 5, 
      tf_trapno = 3, tf_err = 2, tf_eip = 1209228011, tf_cs = 23, 
      tf_eflags = 514, tf_esp = -272639564, tf_ss = 31, tf_vm86_es = 0, 
      tf_vm86_ds = 0, tf_vm86_fs = 0, tf_vm86_gs = 0})
    at ../../../../arch/i386/i386/trap.c:760
#17 0xf0100d7d in syscall1 ()
can not access 0xefbfda38, invalid translation (invalid PDE)
can not access 0xefbfda38, invalid translation (invalid PDE)
Cannot access memory at address 0xefbfda38.

	fsck_lfs says:
rochebonne#/var/crash>fsck_lfs -n /usr/src
** /dev/rwd0f (NO WRITE)
** Last Mounted on /usr/src
** Phase 0 - Check Segment Summaries
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
UNREF FILE I=35838  OWNER=bouyer MODE=100644
SIZE=131068 MTIME=Jan 27 21:32 2000 
CLEAR? no

UNREF FILE I=35842  OWNER=bouyer MODE=100644
SIZE=69828 MTIME=Jan 27 21:33 2000 
CLEAR? no

UNREF FILE I=35844  OWNER=bouyer MODE=100644
SIZE=62120 MTIME=Jan 27 21:33 2000 
CLEAR? no

UNREF FILE I=35855  OWNER=bouyer MODE=100644
SIZE=53208 MTIME=Jan 28 00:28 2000 
CLEAR? no

UNREF FILE I=35870  OWNER=bouyer MODE=100644
SIZE=51212 MTIME=Jan 28 00:28 2000 
CLEAR? no

UNREF FILE I=35883  OWNER=bouyer MODE=100644
SIZE=50308 MTIME=Jan 27 21:54 2000 
CLEAR? no

UNREF FILE I=35888  OWNER=bouyer MODE=100644
SIZE=58576 MTIME=Jan 27 21:55 2000 
CLEAR? no

36112 files, 294841 used, 0 free 

>How-To-Repeat:
	
	'make; rm *.o; make' in a kernel compile directory

>Fix:
	Unknow. Once the problem shows up the only way is to tar the lfs's
	content, newfs it and untar the archive.
>Audit-Trail:
>Unformatted: