On Apr 23, 2007, at 3:05 PM, Antti Kantee wrote:

> I just had one of these with a ~month old kernel:
>
> #9  0xc03e3e01 in pmap_destroy (pmap=3D0xcc6ea04c)
>    at /usr/allsrc/src/sys/arch/i386/i386/pmap.c:1656
> 1656            KASSERT(pmap->pm_obj.uo_npages =3D=3D 0);
>
> #9  0xc03e3e01 in pmap_destroy (pmap=3D0xcc6ea04c)
>    at /usr/allsrc/src/sys/arch/i386/i386/pmap.c:1656
> #10 0xc03e3f5c in pmap_load ()
>    at /usr/allsrc/src/sys/arch/i386/i386/pmap.c:1942
> #11 0xc010c5de in calltrap ()
> #12 0x00000017 in ?? ()
>
> I had just finished updating the kernel sources and typed "make"
> (in the wrong directory, though ;).
>
> Any idea if this is fixed and what should I look for in the dump?

It looks like someone didn't remove all of the mappings from the pmap =20=

before destroying it.  Note that resident_count is 4, which means =20
there are 4 mapping entered in the pmap.  That is consistent with =20
uo_npages being 1 (one page table page).

You could dump the contents of pm_pdir (1024 32-bit PDEs), from there =20=

you can at least figure out what 4MB address range the pages are =20
mapped into.

>
>
> (gdb) print *pmap
> $1 =3D {pm_obj =3D {vmobjlock =3D {lock_data =3D 0 '\0', lock_pad =3D =
"=9F =DE"},
>    pgops =3D 0x0, memq =3D {tqh_first =3D 0xc23bc4c0, tqh_last =3D =20
> 0xc23bc4d0},
>    uo_npages =3D 1, uo_refs =3D 0}, pm_list =3D {le_next =3D =
0xcc6eab48,
>    le_prev =3D 0xcc6ea4d8}, pm_pdir =3D 0xd193c000, pm_pdirpa =3D =20
> 1198936064,
>  pm_ptphint =3D 0xc23bc4c0, pm_stats =3D {resident_count =3D 4, =20
> wired_count =3D 0},
>  pm_hiexec =3D 0, pm_flags =3D 0, pm_ldt =3D 0x0, pm_ldt_len =3D 0, =20=

> pm_ldt_sel =3D 40,
>  pm_cpus =3D 0}
>
> --=20
> Antti Kantee <pooka@iki.fi>                     Of course he runs =20
> NetBSD
> http://www.iki.fi/pooka/                          =
http://www.NetBSD.org/
>    "la qualit=E9 la plus indispensable du cuisinier est l'exactitude"

-- thorpej