Date: Wed, 1 Sep 2010 20:31:10 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Nathaniel W Filardo <nwf@cs.jhu.edu> Cc: freebsd-sparc64@freebsd.org Subject: Re: Inactive pmap? Message-ID: <20100901183110.GA81904@alchemy.franken.de> In-Reply-To: <20100829033124.GO13607@gradx.cs.jhu.edu> References: <20100829033124.GO13607@gradx.cs.jhu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100901183110.GA81904>