Subject: kern/36237: panic in LFS (KASSERT lfs_segment.c:1048)
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: Manuel Bouyer <Manuel.Bouyer@lip6.fr>
List: netbsd-bugs
Date: 04/28/2007 16:25:00
>Number: 36237
>Category: kern
>Synopsis: panic in LFS (KASSERT lfs_segment.c:1048)
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sat Apr 28 16:25:00 +0000 2007
>Originator: Manuel Bouyer
>Release: NetBSD 4.0_BETA2 Apr 27
>Organization:
LIP6/SOC
>Environment:
System: NetBSD rap.lip6.fr 4.0_BETA2 NetBSD 4.0_BETA2 (XEN3_DOM0) #9: Fri Apr 27 22:04:15 MEST 2007 root@cuba:/mnt/4/tmp/i386/obj/home/4/src/sys/arch/i386/compile/XEN3_DOM0 i386
Architecture: i386
Machine: i386
>Description:
I was testing xentools30-hvm with an OS install in an HVM guest.
There was some high disk activity; the virtual disk of the HVM guest
being backed by a 10GB file on a LFS filesystem. At the same time
I was doing some pkgsrc work, on the same filesystem.
The box paniced with:
panic: kernel diagnostic assertion "ip->i_number != LFS_IFILE_INUM || fs->lfs_wr
iter > 0 || (sp->seg_flags & SEGM_CLEAN)" failed: file "/home/4/src/sys/ufs/lfs/
lfs_segment.c", line 1048
Stopped in pid 4771.4 (qemu-dm.bin) at netbsd:cpu_Debugger+0x4: popl
%
ebp
db> tr
cpu_Debugger(c0864880,ccb279b8,cd50bd40,caece698,cca26180) at netbsd:cpu_Debugge
r+0x4
panic(c08c5d28,c082cfab,c088ef54,c088e850,418) at netbsd:panic+0x155
__assert(c082cfab,c088e850,418,c088ef54,cca7765c) at netbsd:__assert+0x2e
lfs_writeinode(c160c800,ccaa0f68,cca7ded8,2000,ffffffff) at netbsd:lfs_writeinod
e+0x433
lfs_segwrite(c166a000,5,4714d4,46336da6,7261400) at netbsd:lfs_segwrite+0x4b9
lfs_vflush(cd4714d4,0,0,1,0) at netbsd:lfs_vflush+0x962
lfs_fsync(ccb27ba8,10002,ccb27bcc,c0486cc7,cd4714d4) at netbsd:lfs_fsync+0xb2
VOP_FSYNC(cd4714d4,caec0f3c,1,0,0) at netbsd:VOP_FSYNC+0x49
sys_fsync(d11d1dec,ccb27c48,ccb27c68,1,ccb27c40) at netbsd:sys_fsync+0xe8
syscall_plain() at netbsd:syscall_plain+0xb3
--- syscall (number 95) ---
>How-To-Repeat:
see above, but it's not reliable
>Fix:
unknown