Re: ufs related panic.

"Garrett Cooper" wrote:
> On Tue, Jun 10, 2008 at 10:38 PM, Ian FREISLICH <ianf_at_clue.co.za> wrote:
> > Hi
> >
> > During the daily periodic jobs shortly after 3am I got this panic.
> > I'll keep the kernel and core on hand for a week or two.
> >
> > Fatal trap 12: page fault while in kernel mode
> > fault virtual address   = 0x0
> > fault code              = supervisor write, page not present
> > instruction pointer     = 0x20:0xc05d9158
> > stack pointer           = 0x28:0xc3b4380c
> > frame pointer           = 0x28:0xc3b43848
> > code segment            = base 0x0, limit 0xfffff, type 0x1b
> >                        = DPL 0, pres 1, def32 1, gran 1
> > processor eflags        = interrupt enabled, resume, IOPL = 0
> > current process         = 1285 (find)
> > trap number             = 12
> > panic: page fault
> > KDB: stack backtrace:
> > db_trace_self_wrapper(c070d276,c3b436ac,c0562952,c070b388,c077c2c0,...) at 
db_tr
> > ace_self_wrapper+0x26
> > kdb_backtrace(c070b388,c077c2c0,c06fa6f5,c3b436b8,c3b436b8,...) at kdb_back
trace
> > +0x29
> > panic(c06fa6f5,c072441f,c42b9a2c,1,1,...) at panic+0xaa
> > trap_fatal(c7b0c1c0,0,2,8,c4479890,...) at trap_fatal+0x2f9
> > trap_pfault(c3b4374c,c05910aa,c42b98c0,c3b4374c,c,...) at trap_pfault+0x240
> > trap(c3b437cc) at trap+0x393
> > calltrap() at calltrap+0x6
> > --- trap 0xc, eip = 0xc05d9158, esp = 0xc3b4380c, ebp = 0xc3b43848 ---
> > vgonel(c76c753c,c3b4387c,2,0,50,...) at vgonel+0x271
> > vnlru_free(0,0,0,0,0,...) at vnlru_free+0x2bb
> > getnewvnode(c070767d,c3f2978c,c0752700,c3b43908,c3b4399c,...) at getnewvnod
e+0x6
> > 8
> > ffs_vget(c3f2978c,91443d,80000,c3b4399c,c3b439ac,...) at ffs_vget+0x104
> > ufs_lookup(c3b439e4,c3b43a04,c05ca463,c0752700,c3b439e4,...) at ufs_lookup+
0xa5e
> > VOP_CACHEDLOOKUP_APV(c0752700,c3b439e4,c3b43bb0,c3b43b9c,c7e82e00,...) at V
OP_CA
> > CHEDLOOKUP_APV+0x44
> > vfs_cache_lookup(c3b43a64,c3b43a1c,c50a8000,80000,c3b43a84,...) at vfs_cach
e_loo
> > kup+0xc6
> > VOP_LOOKUP_APV(c0752700,c3b43a64,c0711327,1b0,c0547229,...) at VOP_LOOKUP_A
PV+0x
> > 48
> > lookup(c3b43b84,c3f2c400,400,c3b43ba4,0,...) at lookup+0x56a
> > namei(c3b43b84,c3b43b24,60,0,c42b98c0,...) at namei+0x480
> > kern_statat(c42b98c0,200,ffffff9c,814d408,0,...) at kern_statat+0x5e
> > kern_lstat(c42b98c0,814d408,0,c3b43c18,c0569524,...) at kern_lstat+0x36
> > lstat(c42b98c0,c3b43cfc,8,c059320c,c42b98c0,...) at lstat+0x2b
> > syscall(c3b43d38) at syscall+0x2fe
> > Xint0x80_syscall() at Xint0x80_syscall+0x20
> > --- syscall (190, FreeBSD ELF32, lstat), eip = 0x2814b853, esp = 0xbfbfeb8c
, ebp
> >  = 0xbfbfec18 ---
> > Uptime: 5d4h27m35s
> > Physical memory: 998 MB
> > Dumping 176 MB: 161 145 129 113 97 81 65 49 33 17 1
> > (kgdb)  bt
> > #0  doadump () at pcpu.h:196
> > #1  0xc0562793 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
> > #2  0xc056298e in panic (fmt=Variable "fmt" is not available.
> > ) at /usr/src/sys/kern/kern_shutdown.c:572
> > #3  0xc06c7ad2 in trap_fatal (frame=0xc3b437cc, eva=0)
> >    at /usr/src/sys/i386/i386/trap.c:934
> > #4  0xc06c7d1e in trap_pfault (frame=0xc3b437cc, usermode=0, eva=0)
> >    at /usr/src/sys/i386/i386/trap.c:847
> > #5  0xc06c863b in trap (frame=0xc3b437cc) at /usr/src/sys/i386/i386/trap.c:
525
> > #6  0xc06b0b6b in calltrap () at /usr/src/sys/i386/i386/exception.s:165
> > #7  0xc05d9158 in vgonel (vp=0xc76c753c) at /usr/src/sys/kern/vfs_subr.c:99
7
> > #8  0xc05dc17b in vnlru_free (count=1) at /usr/src/sys/kern/vfs_subr.c:878
> > #9  0xc05dc2b2 in getnewvnode (tag=0xc070767d "ufs", mp=0xc3f2978c,
> >    vops=0xc0752700, vpp=0xc3b43908) at /usr/src/sys/kern/vfs_subr.c:900
> > #10 0xc0657453 in ffs_vget (mp=0xc3f2978c, ino=9520189, flags=524288,
> >    vpp=0xc3b4399c) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1345
> > #11 0xc0662573 in ufs_lookup (ap=0xc3b439e4)
> >    at /usr/src/sys/ufs/ufs/ufs_lookup.c:599
> > #12 0xc06d12d2 in VOP_CACHEDLOOKUP_APV (vop=0xc0752700, a=0xc3b439e4)
> >    at vnode_if.c:153
> > #13 0xc05ca463 in vfs_cache_lookup (ap=0xc3b43a64) at vnode_if.h:80
> > #14 0xc06d2d21 in VOP_LOOKUP_APV (vop=0xc0752c20, a=0xc3b43a64)
> >    at vnode_if.c:99
> > #15 0xc05d0386 in lookup (ndp=0xc3b43b84) at vnode_if.h:54
> > #16 0xc05d10d8 in namei (ndp=0xc3b43b84) at /usr/src/sys/kern/vfs_lookup.c:
239
> > #17 0xc05df5d7 in kern_statat (td=0xc42b98c0, flag=512, fd=-100,
> >    path=0x814d408 <Address 0x814d408 out of bounds>, pathseg=UIO_USERSPACE,
> >    sbp=0xc3b43c18) at /usr/src/sys/kern/vfs_syscalls.c:2327
> > #18 0xc05df747 in kern_lstat (td=0xc42b98c0,
> >    path=0x814d408 <Address 0x814d408 out of bounds>, pathseg=UIO_USERSPACE,
> >    sbp=0xc3b43c18) at /usr/src/sys/kern/vfs_syscalls.c:2376
> > #19 0xc05df7db in lstat (td=0xc42b98c0, uap=0xc3b43cfc)
> >    at /usr/src/sys/kern/vfs_syscalls.c:2366
> > #20 0xc06c803a in syscall (frame=0xc3b43d38)
> >    at /usr/src/sys/i386/i386/trap.c:1081
> > #21 0xc06b0bd0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s
:261
> > #22 0x00000033 in ?? ()
> 
> Ian,
>       When did you sync / rebuild -CURRENT? I was curious because I've
> been seeing some WITNESS warnings with the FreeBSD FS VM related API's
> recently.

Over the week end.  I've been seeing other weirdness with file
mtimes recently as well.

Ian

--
Ian Freislich