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.