Subject: Re: i386 pmap uvm object dangling pages KASSERT panic
To: Jason Thorpe <thorpej@shagadelic.org>
From: Antti Kantee <pooka@cs.hut.fi>
List: current-users
Date: 04/24/2007 20:24:56
argh! I just realized that I upgraded my HEAD tree *and* the kernel
and that I have only one object dir. so there go the debug symbols.
On Tue Apr 24 2007 at 09:43:27 -0700, Jason Thorpe wrote:
> >#9 0xc03e3e01 in pmap_destroy (pmap=0xcc6ea04c)
> > at /usr/allsrc/src/sys/arch/i386/i386/pmap.c:1656
> >1656 KASSERT(pmap->pm_obj.uo_npages == 0);
> >
> >#9 0xc03e3e01 in pmap_destroy (pmap=0xcc6ea04c)
> > 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
> before destroying it. Note that resident_count is 4, which means
> there are 4 mapping entered in the pmap. That is consistent with
> uo_npages being 1 (one page table page).
For someone who is ~zero familiar with the pmap, the above conclusion
is one of those "it is immediately clear" type things found often in
math books ;)
> You could dump the contents of pm_pdir (1024 32-bit PDEs), from there
> you can at least figure out what 4MB address range the pages are
> mapped into.
(gdb) x/1024x 0xd193c000
0xd193c000: 0x00000000 0x00000000 0x00000000 0x00000000
0xd193c010: 0x00000000 0x00000000 0x00000000 0x00000000
0xd193c020: 0x00000000 0x00000000 0x00000000 0x00000000
0xd193c030: 0x00000000 0x00000000 0x00000000 0x00000000
0xd193c040: 0x00000000 0x00000000 0x00000000 0x00000000
0xd193c050: 0x00000000 0x00000000 0x00000000 0x00000000
0xd193c060: 0x00000000 0x00000000 0x00000000 0x00000000
0xd193c070: 0x00000000 0x00000000 0x00000000 0x00000000
0xd193c080: 0x707bb067 0x00000000 0x00000000 0x00000000
0xd193c090: 0x00000000 0x00000000 0x00000000 0x00000000
....
0xd193cbf0: 0x00000000 0x00000000 0x00000000 0x47765023
0xd193cc00: 0x006f5063 0x006f6063 0x006f7063 0x01000063
0xd193cc10: 0x01001063 0x01002063 0x01003063 0x01004063
0xd193cc20: 0x01005063 0x01006063 0x7fe1c063 0x7fe1d063
0xd193cc30: 0x7fe1a063 0x7fe1b063 0x7fe18063 0x7fe19063
0xd193cc40: 0x7fe16003 0x7fe17003 0x7fe14003 0x7fe15003
0xd193cc50: 0x7fe12003 0x7fe13003 0x7fe10003 0x7fe11003
0xd193cc60: 0x7fe0e003 0x7fe0f003 0x7fe0c003 0x7fe0d003
0xd193cc70: 0x7fe0a003 0x7fe0b003 0x7fe08003 0x7fe09003
0xd193cc80: 0x7fe06003 0x7fe07003 0x7fe04003 0x7fe05003
0xd193cc90: 0x7fe02003 0x7fe03003 0x7fe00003 0x7fe01003
0xd193cca0: 0x7fdfe003 0x7fdff003 0x7fdfc063 0x7fdfd063
0xd193ccb0: 0x7fdfa063 0x7fdfb063 0x7fdf8063 0x7fdf7063
0xd193ccc0: 0x7f9ec063 0x7f9ed063 0x7f375063 0x7f328063
0xd193ccd0: 0x7f329063 0x7eb3b063 0x7e1e9023 0x7dbd4063
0xd193cce0: 0x7cfb8063 0x7af13063 0x710d1063 0x6c67c063
0xd193ccf0: 0x6b7da023 0x6b1ff063 0x68b38063 0x5f895063
0xd193cd00: 0x58a71063 0x55668063 0x4dae4023 0x483bd063
0xd193cd10: 0x475a5063 0x4fbcd063 0x515dd063 0x464ff023
0xd193cd20: 0x4e027023 0x739bf023 0x45e5a023 0x4ef6d023
0xd193cd30: 0x7b8f8023 0x515ce063 0x00000000 0x00000000
0xd193cd40: 0x00000000 0x00000000 0x00000000 0x00000000
....
So if I understood that at all correctly, looks like there's something
mapped at 128MB, something for stack and then the kernel? That's three,
not four. Or am I completely off?
--
Antti Kantee <pooka@iki.fi> Of course he runs NetBSD
http://www.iki.fi/pooka/ http://www.NetBSD.org/
"la qualité la plus indispensable du cuisinier est l'exactitude"