Terry Lambert wrote:
> Nate Lawson wrote:
> > > 0xc02fd315 is in pmap_remove_pages (/usr/src/sys/i386/i386/pmap.c:2941).
> > > 2936 #ifdef PMAP_REMOVE_PAGES_CURPROC_ONLY
> > > 2937 pte = vtopte(pv->pv_va);
> > > 2938 #else
> > > 2939 pte = pmap_pte_quick(pv->pv_pmap, pv->pv_va);
> > > 2940 #endif
> > > 2941 tpte = *pte;
> > > 2942
> > > 2943 if (tpte == 0) {
> > > 2944 printf("TPTE at %p IS ZERO @ VA %08x\n",
> > > 2945 pte, pv->pv_va);
> >
> > Try building your kernel with "options PMAP_REMOVE_PAGES_CURPROC_ONLY" and
> > see if the panic goes away. If that works, the problem is
> > pmap_pte_quick().
> >
> > In looking at pmap_pte_quick, either it is wrong or line 2941 is wrong in
> > always dereferencing pte. pmap_pte_quick can return NULL (well 0). It
> > seems like pmap_pte_quick is wrong because vtopte() never returns NULL,
> > just (PTmap + i386_btop(va)) i.e. a valid base plus some offset.
>
> Obvious fix?
>
> #ifndef PMAP_REMOVE_PAGES_CURPROC_ONLY
> pte = pmap_pte_quick(pv->pv_pmap, pv->pv_va);
> if (pte == NULL)
> #endif
> pte = vtopte(pv->pv_va);
Sorry, no dice. Please read the code a little more.
PMAP_REMOVE_PAGES_CURPROC_ONLY is unconditionally defined, and we check
in pmap_remove_pages() that we are curproc. vtopte() can never fail
in these circumstances - ie: there is always a pointer returned.
The real problem is.. why is the pte null with a pv entry pointing to it?
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
