From owner-freebsd-fs@FreeBSD.ORG Tue Mar 13 18:21:30 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 837651065675 for ; Tue, 13 Mar 2012 18:21:30 +0000 (UTC) (envelope-from mjl@luckie.org.nz) Received: from caida.org (rommie.caida.org [192.172.226.78]) by mx1.freebsd.org (Postfix) with ESMTP id 6B3188FC1A for ; Tue, 13 Mar 2012 18:21:30 +0000 (UTC) Received: from sorcerer.caida.org (sorcerer.caida.org [192.172.226.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by caida.org (Postfix) with ESMTP id 3534BB980 for ; Tue, 13 Mar 2012 11:21:30 -0700 (PDT) Received: from localhost.caida.org ([127.0.0.1] helo=sorcerer.caida.org) by sorcerer.caida.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S7WLi-000Mp9-4K for freebsd-fs@freebsd.org; Tue, 13 Mar 2012 11:21:30 -0700 Message-ID: <4F5F902A.2030108@luckie.org.nz> Date: Tue, 13 Mar 2012 11:21:30 -0700 From: Matthew Luckie User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: freebsd 9.0R panic in vfs_cache.c:364 cache_zap() X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 18:21:30 -0000 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