Date: Tue, 13 Mar 2012 11:21:30 -0700 From: Matthew Luckie <mjl@luckie.org.nz> To: freebsd-fs@freebsd.org Subject: freebsd 9.0R panic in vfs_cache.c:364 cache_zap() Message-ID: <4F5F902A.2030108@luckie.org.nz>
next in thread | raw e-mail | index | archive | help
Hi This is likely to be a useless report because I don't have a crash dump. I upgraded to freebsd 9.0R on Friday night and last night (Monday) it panicked during a nightly rsync. First time I've had a panic during a nightly rsync on this machine, which has been running for about two years. I searched lists to see if there was a known problem but didn't come across anything, and I'm not sure what to search for. There seem to have been a few commits on RELENG_9 to vfs_cache.c since release, is it worthwhile upgrading to a 9-stable? $ addr2line -e /boot/kernel/kernel.symbols 0xc0a9754d /usr/src/sys/kern/vfs_cache.c:364 The numbers marked with # correspond to the frames below $ addr2line -e /boot/kernel/kernel.symbols 0xc0a977e8 0xc0aabe89 0xc0ab061b 0xc0ab0769 0xc0c5f589 0xc0c5fa5e 0xc0c6d7dc 0xc0c6d86a 0xc0d772e2 0xc0a99206 0xc0d791e6 #6 /usr/src/sys/kern/vfs_cache.c:816 #7 /usr/obj/usr/src/sys/spandex/./machine/pcpu.h:244 #8 /usr/obj/usr/src/sys/spandex/./vnode_if.h:879 #9 /usr/src/sys/kern/vfs_subr.c:994 #10 /usr/src/sys/ufs/ffs/ffs_vfsops.c:1616 #11 /usr/src/sys/ufs/ffs/ffs_vfsops.c:1561 #12 /usr/src/sys/ufs/ufs/ufs_lookup.c:749 #13 /usr/src/sys/ufs/ufs/ufs_lookup.c:215 #14 /usr/obj/usr/src/sys/spandex/vnode_if.c:187 #15 /usr/obj/usr/src/sys/spandex/./vnode_if.h:80 #16 /usr/obj/usr/src/sys/spandex/vnode_if.c:123 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x15 fault code = supervisor write, page not present instruction pointer = 0x20:0xc0a9754d stack pointer = 0x28:0xed94f744 frame pointer = 0x28:0xed94f758 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 = 78950 (rsync) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xc0a4e9d7 at kdb_backtrace+0x47 #1 0xc0a1bf37 at panic+0x117 #2 0xc0d57013 at trap_fatal+0x323 #3 0xc0d570cd at trap_pfault+0xad #4 0xc0d57e55 at trap+0x465 #5 0xc0d40dac at calltrap+0x6 #6 0xc0a977e8 at cache_purge+0x68 #7 0xc0aabe89 at vgonel+0x2d9 #8 0xc0ab061b at vnlru_free+0x2bb #9 0xc0ab0769 at getnewvnode+0x69 #10 0xc0c5f589 at ffs_vgetf+0x109 #11 0xc0c5fa5e at ffs_vget+0x2e #12 0xc0c6d7dc at ufs_lookup_ino+0xaec #13 0xc0c6d86a at ufs_lookup+0x2a #14 0xc0d772e2 at VOP_CACHEDLOOKUP_APV+0x42 #15 0xc0a99206 at vfs_cache_lookup+0xd6 #16 0xc0d791e6 at VOP_LOOKUP_APV+0x46 Matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F5F902A.2030108>