From owner-freebsd-sparc64@FreeBSD.ORG Wed Sep 1 18:31:15 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED2ED10656C0 for ; Wed, 1 Sep 2010 18:31:14 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 7BF118FC2F for ; Wed, 1 Sep 2010 18:31:14 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o81IVBLb082079; Wed, 1 Sep 2010 20:31:11 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o81IVAbF082078; Wed, 1 Sep 2010 20:31:10 +0200 (CEST) (envelope-from marius) Date: Wed, 1 Sep 2010 20:31:10 +0200 From: Marius Strobl To: Nathaniel W Filardo Message-ID: <20100901183110.GA81904@alchemy.franken.de> References: <20100829033124.GO13607@gradx.cs.jhu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100829033124.GO13607@gradx.cs.jhu.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org Subject: Re: Inactive pmap? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 18:31:15 -0000 On Sat, Aug 28, 2010 at 11:31:24PM -0400, Nathaniel W Filardo wrote: > I've been getting a few of these over the past while. I don't believe > there's a hardware problem. The hardware is a stock V240 uniprocessor > machine. > > FreeBSD hydra.priv.oc.ietfng.org 8.1-STABLE FreeBSD 8.1-STABLE #18 > r211472+d3b8a13: Fri Aug 20 00:54:00 EDT 2010 > root@hydra.priv.oc.ietfng.org:/systank/obj/systank/src/sys/NWFKERN sparc64 > > panic() at panic+0x1c8 > tlb_page_demap() at tlb_page_demap+0x148 > pmap_cache_enter() at pmap_cache_enter+0x1dc > pmap_kenter() at pmap_kenter+0x1b4 > pmap_qenter() at pmap_qenter+0x78 > sf_buf_alloc() at sf_buf_alloc+0x160 > zfs_freebsd_read() at zfs_freebsd_read+0x2cc > VOP_READ_APV() at VOP_READ_APV+0x108 > VOP_READ_AP() at VOP_READ_AP+0xc > null_bypass() at null_bypass+0x124 > VOP_READ_APV() at VOP_READ_APV+0x11c > vn_read() at vn_read+0x240 > dofileread() at dofileread+0x74 > kern_preadv() at kern_preadv+0x68 > pread() at pread+0x50 > syscall() at syscall+0x25c > -- syscall (475, FreeBSD ELF64, pread) %o7=0x4022d784 -- > userland() at 0x4022fa48 > user trace: trap %o7=0x4022d784 > pc 0x4022fa48, sp 0x7fdffffd891 > pc 0x4022b474, sp 0x7fdffffd9a1 > pc 0x4022b6b0, sp 0x7fdffffdcb1 > pc 0x4022c84c, sp 0x7fdffffdd71 > pc 0x40226e74, sp 0x7fdffffe4d1 > done > Uptime: 5d3h53m14s > > and > > FreeBSD hydra.priv.oc.ietfng.org 8.1-STABLE FreeBSD 8.1-STABLE #17 > r210985+7fd3af5: Sat Aug 7 14:25:03 EDT 2010 > root@hydra.priv.oc.ietfng.org:/systank/obj/systank/src/sys/NWFKERN sparc64 > > panic: tlb_page_demap: inactive pmap? > cpuid = 0 > KDB: stack backtrace: > panic() at panic+0x1c8 > tlb_page_demap() at tlb_page_demap+0x148 > pmap_cache_remove() at pmap_cache_remove+0x1a0 > pmap_kremove() at pmap_kremove+0x120 > pmap_qremove() at pmap_qremove+0x74 > sf_buf_free() at sf_buf_free+0x8 > zfs_freebsd_read() at zfs_freebsd_read+0x2f4 > VOP_READ_APV() at VOP_READ_APV+0x108 > VOP_READ_AP() at VOP_READ_AP+0xc > null_bypass() at null_bypass+0x124 > VOP_READ_APV() at VOP_READ_APV+0x11c > vn_read() at vn_read+0x240 > dofileread() at dofileread+0x74 > kern_preadv() at kern_preadv+0x68 > pread() at pread+0x50 > syscall() at syscall+0x25c > -- syscall (475, FreeBSD ELF64, pread) %o7=0x4020f784 -- > userland() at 0x40211a48 > user trace: trap %o7=0x4020f784 > pc 0x40211a48, sp 0x7fdffffd891 > pc 0x4020d474, sp 0x7fdffffd9a1 > pc 0x4020d6b0, sp 0x7fdffffdcb1 > pc 0x4020e84c, sp 0x7fdffffdd71 > pc 0x40208e74, sp 0x7fdffffe4d1 > done > Uptime: 8d4h57m37s > > Suggestions? Hrm, it seems next to impossible that this assertion is violated, especially on UP, as pm_active and pm_context are updated together, either with a lock held or when locking shouldn't be necessary yet. Are you running a kernel with or without options SMP on this machine? Could you please test whether the following patch makes a difference? http://people.freebsd.org/~marius/sparc64_pmap_pinit.diff Marius