Inactive pmap?

[Marius Strobl]

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 at 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 at 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