panic on fresh -CURRENT

[Konstantin Belousov]

On Sun, May 11, 2014 at 09:37:43AM +0200, Michael Moll wrote:
> Hi,
> 
> On Sun, May 11, 2014 at 12:56:47AM +0300, Konstantin Belousov wrote:
> > Still, does it work if you revert the r265843 ?
> 
> Leads to the same panic.
> 
> > Do you have INVARIANTS defined in your kernel config ?
> 
> No. But would be no problem, if it helps to track down the problem.
> 
> > Do you have vmcore from the panic ? If yes, please load it
> > in kgdb and do p *(struct vm_page *)0xfffff800fc480870.
> 
> Sure, here we go:
> 
> panic: vm_page_free: freeing wired page 0xfffff800fb7f6d98
> cpuid = 0
> KDB: stack backtrace:
> panic() at panic+0x1d4
> vm_page_free_toq() at vm_page_free_toq+0xa0
> vm_page_free_zero() at vm_page_free_zero+0x10
> pmap_release() at pmap_release+0xe4
> vmspace_exit() at vmspace_exit+0x104
> exit1() at exit1+0x6d4
> sigexit() at sigexit+0xb94
> postsig() at postsig+0x194
> ast() at ast+0x44c
> -- syscall (7, FreeBSD ELF64, sys_wait4) %o7=0x1027e8 --
> userland() at 0x156484
> user trace: trap %o7=0x1027e8
> pc 0x156484, sp 0x7fdffffd501
> panic: trap: fast data access mmu miss (kernel)
> cpuid = 0
> KDB: enter: panic
> 
> [...]
> (kgdb) p *(struct vm_page *)0xfffff800fb7f6d98
> $1 = {plinks = {q = {tqe_next = 0xfffff800fb7f6e10, tqe_prev = 0xfffff800fb7f6ca8}, s = {ss = {sle_next = 0xfffff800fb7f6e10}, pv = 0xfffff800fb7f6ca8}, memguard = {
>       p = 18446735281835961872, v = 18446735281835961512}}, listq = {tqe_next = 0xfffff800fb7f6e10, tqe_prev = 0xfffff80013644248}, object = 0x0, pindex = 9, 
>   phys_addr = 3448094720, md = {tte_list = {tqh_first = 0xec36f1e0, tqh_last = 0xec36f1f0}, pmap = 0x0, colors = {0, 0}, color = 0}, wire_count = 4294967295, 
>   busy_lock = 1, hold_count = 0, flags = 8, aflags = 0 '\0', oflags = 0 '\0', queue = 255 '???', segind = 0 '\0', order = 12 '\f', pool = 0 '\0', act_count = 9 '\t', 
>   valid = 0, dirty = 0}

There are two things wrong with the page.  One, the obvious issue,
is that wire_count is -1, i.e. the manual decrement underflown.
The other issue is that the page is not marked as unmanaged, which
is quite strange.

Please try the following patch, it slightly modernizes the tsb page free
sequence to the current VM KPI, and also adds assertions which reflect
my understanding of the correct state of the tsb object and pages.
The patch is not a fix, it only should somewhat improve debugging.
And yes, enable INVARIANTS.

diff --git a/sys/sparc64/sparc64/pmap.c b/sys/sparc64/sparc64/pmap.c
index 28fcb1f..eb3582e 100644
--- a/sys/sparc64/sparc64/pmap.c
+++ b/sys/sparc64/sparc64/pmap.c
@@ -1226,9 +1226,14 @@ pmap_pinit(pmap_t pm)
 	CPU_ZERO(&pm->pm_active);
 
 	VM_OBJECT_WLOCK(pm->pm_tsb_obj);
+	KASSERT(pm->pm_tsb_obj->resident_page_count == 0,
+	    ("tsb_obj %p rpc %d", pm->pm_tsb_obj,
+	    pm->pm_tsb_obj->resident_page_count));
 	for (i = 0; i < TSB_PAGES; i++) {
 		m = vm_page_grab(pm->pm_tsb_obj, i, VM_ALLOC_NOBUSY |
 		    VM_ALLOC_WIRED | VM_ALLOC_ZERO);
+		KASSERT(m->wire_count == 1, ("tsb_obj %p m %p wc %u",
+		    pm->pm_tsb_obj, m, m->wire_count));
 		m->valid = VM_PAGE_BITS_ALL;
 		m->md.pmap = pm;
 		ma[i] = m;
@@ -1289,11 +1294,13 @@ pmap_release(pmap_t pm)
 	obj = pm->pm_tsb_obj;
 	VM_OBJECT_WLOCK(obj);
 	KASSERT(obj->ref_count == 1, ("pmap_release: tsbobj ref count != 1"));
+	KASSERT(pm->pm_tsb_obj->resident_page_count == TSB_PAGES,
+	    ("tsb_obj %p rpc %d", pm->pm_tsb_obj,
+	    pm->pm_tsb_obj->resident_page_count));
 	while (!TAILQ_EMPTY(&obj->memq)) {
 		m = TAILQ_FIRST(&obj->memq);
 		m->md.pmap = NULL;
-		m->wire_count--;
-		atomic_subtract_int(&vm_cnt.v_wire_count, 1);
+		vm_page_unwire(m, 0);
 		vm_page_free_zero(m);
 	}
 	VM_OBJECT_WUNLOCK(obj);
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20140511/77f3a273/attachment.sig>