Subject: kern/32927: KASSERT(pmap->pm_obj.uo_npages == 0) failed on x86 3.99.13
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: None <simonb@wasabisystems.com>
List: netbsd-bugs
Date: 02/25/2006 07:55:00
>Number:         32927
>Category:       kern
>Synopsis:       KASSERT(pmap->pm_obj.uo_npages == 0) failed on x86 3.99.13
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Feb 25 07:55:00 +0000 2006
>Originator:     Simon Burge
>Release:        NetBSD 3.99.13, sources from 2005/12/09
>Organization:
Wasabi Systems
>Environment:
System: NetBSD bigkev.thistledown.com.au 3.99.13 NetBSD 3.99.13
    (BIGKEV) #52: Fri Dec 9 10:15:26 EST 2005
    simonb@bigkev:/var/tmp/BIGKEV i386
Architecture: i386
Machine: i386
SMP
>Description:
	While a couple of build.sh's were running, on a dual cpu
	x86 with 512MB of RAM, I got the following kassert:

panic: kernel diagnostic assertion "pmap->pm_obj.uo_npages == 0" failed: file
    "sys/arch/i386/i386/pmap.c", line 1751

	The trace on one CPU is:

cpu_Debugger(6,42c1d80,0,0,caf090c8) at netbsd:cpu_Debugger+0x4
panic(c08742a0,c07b5d8b,c07d39f4,c07d39b3,6d7) at netbsd:panic+0x121
__main(c07b5d8b,c07d39b3,6d7,c07d39f4,c165c000) at netbsd:__main
pmap_destroy(caf090c8,cc6194ac,cb97ff90,202,0) at netbsd:pmap_destroy+0x11d
pmap_load(1f,1f,bfbf001f,bbbd001f,0) at netbsd:pmap_load+0x151

	and the other is:

db{6}> bt
_kernel_lock_acquire_count(1,0,cbd3fe8c,c03e9cbd,c0888c34) at netbsd:_kernel_lock_acquire_count+0x95
mi_switch(cbbbb3a0,0,1d8,c,fffffffe) at netbsd:mi_switch+0x1b1
ltsleep(cbdbfc90,120,c07b8067,0,0) at netbsd:ltsleep+0x4d0
find_stopped_child(cbdbfc90,ffffffff,0,cbd3ff30,c0888c34) at netbsd:find_stopped_child+0xdc
sys_wait4(cbbbb3a0,cbd3ff64,cbd3ff5c,c0886af4,c03d707b) at netbsd:sys_wait4+0x44
syscall_plain() at netbsd:syscall_plain+0x1a5
--- syscall (number 7) ---

	I have a crash dump too of the system, and a .gdb kernel.
	The first attempt to get a crash dump with "sync" got a:

	    panic: TLB IPI rendezvous failed (mask 1)

	but a second "sync" got a crash dump.

>How-To-Repeat:
	Not sure.

>Fix:
	None given.  These sources are about 2 months old, but nothing
	looks to have changed recently around the x86 pmap.